One document matched: draft-ietf-16ng-ip-over-ethernet-over-802.16-02.txt
Differences from draft-ietf-16ng-ip-over-ethernet-over-802.16-01.txt
Network Working Group HS. Jeon
Internet-Draft ETRI
Intended status: Standards Track M. Riegel
Expires: January 10, 2008 NSN
SJ. Jeong
ETRI
July 9, 2007
Transmission of IP over Ethernet over IEEE 802.16 Networks
draft-ietf-16ng-ip-over-ethernet-over-802.16-02.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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the transmission of IPv4 over Ethernet as
well as IPv6 over Ethernet in an access network deploying the IEEE
802.16 cellular radio transmission technology. The Ethernet on top
of IEEE 802.16 is realized by bridging between point-to-point radio
links, which are provided by IEEE 802.16 between the base station and
Jeon, et al. Expires January 10, 2008 [Page 1]
Internet-Draft IPoEth over IEEE 802.16 July 2007
its associated subscriber stations. Due to the resource constraints
of radio transmission systems and the limitations of the IEEE 802.16
MAC functionality for the realization of an Ethernet, the
transmission of IP over Ethernet over IEEE 802.16 may considerably
benefit by adding IP specific support functions in the Ethernet over
IEEE 802.16 while maintaining full compatibility with standard IP
over Ethernet behavior.
Jeon, et al. Expires January 10, 2008 [Page 2]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 5
4.1. Connection Oriented Air Interface . . . . . . . . . . . . 5
4.2. Feeding User Data into the Appropriate Connections . . . . 6
4.3. MAC addressing in IEEE 802.16 . . . . . . . . . . . . . . 6
5. Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . . 6
5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 6
5.2. Ethernet without Native Broadcast and Multicast Support . 8
5.3. Segmenting the Ethernet into VLAN . . . . . . . . . . . . 8
5.4. Deployment Scenarios for IP over Ethernet over IEEE
802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Public Access Scenario . . . . . . . . . . . . . . . . 8
5.4.2. Enterprise LAN Scenario . . . . . . . . . . . . . . . 9
6. Bridge Considerations . . . . . . . . . . . . . . . . . . . . 10
6.1. Multicast and Broadcast Packet Processing . . . . . . . . 10
6.1.1. Multicast Transmission Considerations . . . . . . . . 11
6.1.2. Broadcast Transmission Considerations . . . . . . . . 11
6.2. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Public Access Scenario Case . . . . . . . . . . . . . 12
6.2.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . 12
7. Access Router Considerations . . . . . . . . . . . . . . . . . 12
8. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Public Access Scenario Case . . . . . . . . . . . . . . . 13
8.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . . . 13
9. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 13
9.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 13
9.1.1. Address Configuration . . . . . . . . . . . . . . . . 13
9.1.2. Address Resolution . . . . . . . . . . . . . . . . . . 14
9.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 14
9.2.1. Router Discovery, Prefix Discovery and Parameter
Discovery . . . . . . . . . . . . . . . . . . . . . . 14
9.2.2. Address Configuration . . . . . . . . . . . . . . . . 14
9.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 14
9.3. Maximum Transmission Unit Consideration . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Multicast CID Deployment Considerations . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Jeon, et al. Expires January 10, 2008 [Page 3]
Internet-Draft IPoEth over IEEE 802.16 July 2007
1. Introduction
IEEE 802.16 [IEEE802.16] defines a PMP (Point-to-Multipoint) radio
transmission system connecting a BS (Base Station) with multiple SSs
(Subscriber Stations). IEEE 802.16e [IEEE802.16e] amends the base
specification with PHY and MAC functions for supporting mobile
terminals while adopting the same data link principles also for
mobile networking systems.
Ethernet is a widely deployed transmission technology. It provides
unicast transport, handles broadcast and multicast traffic
efficiently and provides rich services such as Virtual LANs.
However, Ethernet has been originally architected and designed for a
shared medium without special considerations for advanced wireless
transmission systems. The focus on wired systems requires additional
support functions when Ethernet is employed in the IEEE 802.16.
This document describes the transmission of IPv4 over Ethernet as
well as IPv6 over Ethernet in an access network deploying the IEEE
802.16 cellular radio transmission technology. The Ethernet on top
of IEEE 802.16 is realized by bridging between the point-to-point
radio links, which are provided by IEEE 802.16 between the BS and its
associated SSs.
With the resource constraints of radio transmission systems and the
particularities of the IEEE 802.16 MAC for the realization of
Ethernet, it makes sense to add IP specific support functions in the
Ethernet layer above IEEE 802.16 while maintaining full compatibility
with standard IP over Ethernet behavior. Those IP specific support
functions are preferable realized in a centralized device containing
also the bridge for aggregation of traffic from all the BSs to
provide a more straightforward management solution and allow for
effectively commoditized BSs, which are deployed in the IEEE 802.16
based access network in large volume.
2. Requirements
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].
3. Terminology
The terminology in this document is based on the definitions in IP
over 802.16 Problem Statement and Goals [I-D.ietf-16ng-ps-goals].
Jeon, et al. Expires January 10, 2008 [Page 4]
Internet-Draft IPoEth over IEEE 802.16 July 2007
4. The IEEE 802.16 Link Model
4.1. Connection Oriented Air Interface
The IEEE 802.16 MAC establishes multiple connections between a BS and
its associated SSs for the transfer of user data over the air. Each
of these connections realize an individual Service Flow which is
identified by a 16 bit CID number and has a defined QoS profile.
Multiple connections can be established between a BS and a SS, each
with its particular QoS class and direction. Although the BS and all
the SS are associated with unique 48-bit MAC addresses, packets going
over the air are only identified in the IEEE 802.16 MAC header by the
CID number of the particular connection. The connections are
established by MAC management messages between the BS and the SS
during network entry or also later on demand. Unique cryptographic
keys are generated during the initial authentication phase between
the BS and each of the associated SSs to protect the data
transmission over the air.
While uplink connections from the SSs to the BS provide only unicast
transmission capabilities, downlink connections can be used for
multicast transmission to a group of SSs as well as unicast
transmission from the BS to a single SS. The use of multicast CIDs
for realizing mulicast transmissions, however, is depreciated because
of the reduced transmission efficiency in smaller groups and the
complexity of the management of mulitcast CIDs in the BSs as well as
in the SSs.
Appendix A provides an overview about the issues arising with
multicast CIDs in IEEE 802.16 systems.
| | | | | |
+--+--+ +--+--+ +--+--+ +--+-+-+--+
| MAC | | MAC | | MAC | | MAC |
+-----+ +-----+ +-----+ +---------+
| PHY | | PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+
| | | | | | | | | |
| +-------|-+-------|-+----CID#w----+ | | |
| | +------CID#x------+ | |
| +----------------CID#y--------+ |
+--------------------------CID#z----------+
SS#1 SS#2 SS#3 BS
Figure 1. Basic IEEE 802.16 Link Model
Jeon, et al. Expires January 10, 2008 [Page 5]
Internet-Draft IPoEth over IEEE 802.16 July 2007
4.2. Feeding User Data into the Appropriate Connections
Assignment of higher layer packets to particular Service Flows and
related CIDs is performed by the convergence sublayer within the IEEE
802.16 MAC. It classifies the packets depending of the values in the
defined set of the payload packet header fields and assigns the
packets to the appropriate Service Flow.
To enable the transmission of different kind of payloads over IEEE
802.16, multiple convergence sublayers are defined, each specific for
one kind of payload packet type, like Ethernet, IPv4, IPv6 or even
for encapsulated payload, like IPv4 over Ethernet or IPv6 over
Ethernet.
4.3. MAC addressing in IEEE 802.16
The 48-bit unique MAC address of a SS is used during the initial
ranging process for the identification of a SS and is verified by the
succeeding PKMv2 authentication phase. Out of the successful
authentication, the BS establishes and maintains the list of attached
SSs based on their MAC addresses purely for MAC management purposes.
While MAC addresses are assigned to all the SSs as well as to the BS
the forwarding of packets over the air is performed only on base of
the CID value. Not relying on the MAC addresses in the payload for
reception of a radio frame allows for the transport of arbitrary
source and destination MAC addresses in Ethernet frames between a SS
and its BS. This is beneficial when Ethernet frames with arbitrary
MAC addresses have to be forwarded to an SS in the case that the SS
contains an Ethernet bridge for a network behind the SS.
Due to the managed assignment of the service flows and associated CID
values to individual SSs, the BS is able to bundle all connections
belonging to a particular SS to a single link towards the bridge on
the network side to provide plain layer 2 forwarding behaviour in the
BS between the radio link towards the SS and its associated wired
link on the network side.
5. Ethernet Network Model for IEEE 802.16
5.1. IEEE 802.16 Ethernet Link Model
According to [I-D.ietf-ipv6-rfc2461bis], 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. IEEE 802.16
provides point-to-point connections between SSs and the BS but does
not enable any direct SS to SS connectivity.
Jeon, et al. Expires January 10, 2008 [Page 6]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Ethernet is realized over IEEE 802.16 by implementing bridging
according to [IEEE802.1D] and its amendment [IEEE802.16k] between all
SSs based on the IEEE 802.16 Ethernet link model, which provides
point-to-point connections between the hosts and the bridge behind
the BS as shown in Figure 2. This is equivalent to today's switched
Ethernet with twisted pair wires connecting the hosts to a bridge
("Switch").In the IEEE 802.16 Ethernet link model, the BS forwards
the radio links into wired links towards the bridge. Separation of
multiple links on the connection between the BS and the bridge can be
achieved by deploying flow identifiers (e.g. VLAN-IDs or GRE KEYS)
on the wired path.
The BS SHALL forward all the Service Flows belonging to one SS to one
radio side port of a bridge according to [IEEE802.1D] and its
amendment [IEEE802.16k] behind the BSs. No more than one SS SHALL be
connected to one port of the bridge.
The bridge SHOULD be able to create a new port whenever a new SS
attaches to any of the BSs of the network or to remove a port when an
associated SS detaches from the network.
If the SS functions as a bridge for multiple hosts behind the SS
(i.e. SS#4 in the below figure) then the SS SHOULD support bridging
according to [IEEE802.1D] and its amendment [IEEE802.16k] between all
its LAN ports and the IEEE 802.16 air link.
------------------------ IP Link --------------------------
| | | | | |
ETH ETH ETH ETH ETH ETH
| | | | | |
| | +---------+---------+ | +-+---+-+
| | | Bridge | | |Bridge |
| | +--+-+---------+-+--+ | +---+---+
| | | | | | | |
+--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+
| MAC | | MAC | | MAC | | MAC | | MAC | | MAC |
+-----+ +-----+ +-------+ +-------+ +-----+ +-----+
| PHY | | PHY | | PHY | | PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+
| | | | | | | | | | | | | |
| +-------|-+--CID#u-+ | | | | +-CID#x--+-|-------+ |
| +----CID#v---+ | | +---CID#y----+ |
+--------------CID#w-----+ +-----CID#z--------------+
SS#1 SS#2 BS#1 BS#2 SS#3 SS#4
Figure 2. IEEE 802.16 Ethernet Link Model
Jeon, et al. Expires January 10, 2008 [Page 7]
Internet-Draft IPoEth over IEEE 802.16 July 2007
5.2. Ethernet without Native Broadcast and Multicast Support
Current IEEE 802.16 [IEEE802.16][IEEE802.16e] does not define
broadcast and multicast of IP packets. Also, MBS (Multicast and
Broadcast Service as specified in 6.3.23 of [IEEE802.16e]) does not
cover IP broadcast or multicast data because MBS is invisible to IP
layer. Furthermore MBS has severe radio and management issues, as
discussed in Appendix A. Hence IP broadcast and multicast packets
SHOULD be replicated and then carried via unicast transport
connections as IEEE 802.16 access link. As specified in Section 6,
the bridge performs the replication and forwarding.
5.3. Segmenting the Ethernet into VLAN
It is possible to restrict the size and coverage of an IP link by
segmenting the Ethernet and grouping subsets of hosts into VLANs.
Therefore, the bridge behind the BSs MAY be enabled to support VLANs
according to [IEEE802.1Q] by assigning and handling the VLAN- IDs of
the virtual bridge ports.
If a SS itself contains a VLAN enabled bridge or is directly
connected to a bridge supporting VLANs, the port associated with such
a SS MAY be enabled as trunk port. On trunk ports, Ethernet frames
are forwarded in the [IEEE802.1Q] frame format.
5.4. Deployment Scenarios for IP over Ethernet over IEEE 802.16
This section discusses the two possible deployment scenarios in case
of IP over Ethernet over IEEE 802.16: Public Access scenario and
Enterprise LAN scenario.
In both scenarios, an AR is connected to a bridge, which is connected
to all BSs. The bridge acts as aggregation point for all the
connections from SSs. Multiple ARs can exist on a link, and an IP
Link may consist of multiple hosts either being co-located with a SS
or behind a SS connected to a bridge. The network behind a SS can
support various access network technologies, e.g. 802.3, 802.11 or
802.15.
There is a big difference between the scenarios in terms of the
service provider policies. The difference is also reflected in
Section 6.2 and Section 8.
5.4.1. Public Access Scenario
In the Public Access scenario, direct communication between nodes is
restricted because of security and accounting issues. Figure 3
depicts the public access scenario.
Jeon, et al. Expires January 10, 2008 [Page 8]
Internet-Draft IPoEth over IEEE 802.16 July 2007
In the scenario, the AR is connected to a network side port of the
bridge behind the BSs. The bridge SHOULD forward all packets
received from any radio side port to all network side ports being in
the forwarding state. Peer-to-peer communication SHOULD NOT be
supported by the bridge and all packets originated from a SS SHOULD
be delivered to an AR. The AR SHOULD perform security filtering,
policing and accounting of all traffic from hosts, e.g. like a NAS
(Network Access Server).
+--+
|SS|
+--+*
*
* +----+
+--+ * | +-------+
|SS|* * * * **| BS +------+ \
+--+ * | +-----+ \ \ +---+
+--+ * +----+ \ \ +-+ B |
|SS|* \ +--+ R |
+--+ +---+ I | +----+
+----+ | D +---+ AR +--Internet
|Host+ +--+ G | +----+
+----+\ +----+ / +-+ E |
+----+ +------+--+ | +---+ / +---+
|Host+-+BRIDGE|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +--+ *
+----+ |SS|*
+--+
Figure 3. Public Access Scenario
While the bridge forces all traffic from hosts to reach the AR, it
still performs Learning Process and maintains Filtering Database as
specified in [IEEE802.1D] and then forwards IP unicast packets from
the AR based on the Filtering Database. However, IP broadcast and
multicast packets SHOULD be treated with special rules as stated in
Section 6.1.
5.4.2. Enterprise LAN Scenario
The enterprise LAN scenario assumes trust relationship between all
hosts and thus enables hosts to directly communicate with each other
without detouring. Multiple ARs may be connected to a link, and ARs
Jeon, et al. Expires January 10, 2008 [Page 9]
Internet-Draft IPoEth over IEEE 802.16 July 2007
may reside on both sides of the radio link, on the network side of
the bridge behind the BSs as well as behind a SS connected to a
bridge. Figure 4 depicts the enterprise LAN scenario network model.
IP unicast packets from either SSs or AR SHALL be forwarded by
[IEEE802.1D] based bridging. IP broadcast and multicast packets
SHOULD be processed in the bridge according to rules presented in
Section 6.1.
+--+
|SS|
+--+*
* +----+
* +----+ +Host|
+--+ * | +-------+ /+----+
|SS|* * * * **| BS +------+ \ / +----+
+--+ * | +-----+ \ \ +---+/ ++Host|
+--+ * +----+ \ \ +-+ B + / +----+
|SS|* \ +--+ R ++
+----+ +--+ +---+ I | +----+
--+ AR ++ | D +---+ AR +---
+----+ \ +--+ G | +----+
\ +----+ / +-+ E |
+----+ +------+--+ | +---+ / +---+
|Host+-+BRIDGE|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +--+ *
+----+ |SS|*
+--+
Figure 4. Enterprise LAN Scenario
6. Bridge Considerations
This section discusses operations of the bridge behind the BSs
6.1. Multicast and Broadcast Packet Processing
All multicast and multicast control messages SHOULD be processed in
the bridge according to [RFC4605]. Broadcasting messages to all
radio side ports of the bridge SHOULD be prevented.
Further information on prevention of multicasting or broadcasting
messages to all radio side ports are given in the following sections.
Jeon, et al. Expires January 10, 2008 [Page 10]
Internet-Draft IPoEth over IEEE 802.16 July 2007
6.1.1. Multicast Transmission Considerations
Usually, the bridge replicates the IP multicast packets like IP
broadcast packets into all its available ports with the exception of
the incoming port. As a result, the IP multicast packets would be
transmitted even to SSs which do not participate in the corresponding
multicast group. To allow bridges to handle IP multicast more
efficiently the IP multicast membership should be propagated between
bridges.
IGMP/MLD proxying in [RFC4605] is a simple mechanism for multicast
packets forwarding based on the Internet Group Management Protocol
(IGMP) or Multicast Listener Discovery (MLD) membership information,
which works only in a basic tree topology. An IGMP/MLD proxy device
does learning and proxying group membership information and forwards
the IP multicast packets based on the membership information.
Typically, the proxy device is located at an aggregation point, which
has a single upstream interface and multiple downstream interfaces.
The IEEE 802.16 Ethernet link model in Section 5.1 has a simple tree
topology and [RFC4541] provides an application guide how bridge,
non-IP device, to examine and learn group membership. Hence,
[RFC4605] can be applied to the IEEE 802.16 Ethernet link model to
reduce the multicast packet flooding.
The bridge in the IEEE 802.16 Ethernet link model SHOULD play a role
in proxying IGMP/MLD messages as specified in [RFC4605]. The bridge
SHOULD perform the host portion of IGMP/MLD process on its network
side port and the router portion of IGMP/MLD process on its all radio
side ports. Note that the bridge SHOULD perform IGMP/MLD Querier on
only radio side ports, which are already subscribed with received
IGMP/MLD membership report messages. This is due to the reduction of
flooding of IGMP/MLD Query messages. The bridge SHOULD maintain
subscription information on each radio side port with received IGMP/
MLD membership report messages and forward multicast packets from a
network side port to radio side ports based on the subscription
information. In case of multicast packets from radio side ports, the
bridge SHOULD forward the packets to a network side port as well as
radio side ports, except the incoming radio side port, based on the
subscription information.
6.1.2. Broadcast Transmission Considerations
The bridge typically floods the IP broadcast packets out of all
connected ports except the port on which the packet was received.
This behaviour in not appropriate with scarce resources and dormant-
mode hosts in a wireless network such as an IEEE 802.16 based access
network.
Jeon, et al. Expires January 10, 2008 [Page 11]
Internet-Draft IPoEth over IEEE 802.16 July 2007
The bridge in the IEEE 802.16 Ethernet link model SHOULD discard all
IP broadcast packets except ARP, DHCP (DHCPv4 and DHCPv6), IGMP, and
MLD related traffic. The ARP, DHCP, IGMP and MLD related packets
SHOULD be forwarded with special rules specified in this
specification. Note that packets destined for permanently assigned
multicast addresses such as 224.0.0.0/24 in IPv4 or FF02::1 in IPv6
are also regarded as broadcast data.
6.2. Proxy ARP
Proxy ARP provides a process where a device on the link between hosts
answers ARP Requests instead of the remote host. In this
specification, the Proxy ARP mechanism is used to force all traffic
from hosts to the access router and to avoid broadcasting ARP
Requests over the air depending on the particular deployment
scenario. The Proxy ARP process is usually co-located with the
bridge behind the BS.
6.2.1. Public Access Scenario Case
The bridge behind the BSs SHOULD filter broadcast ARP Requests and
SHOULD respond to all the ARP Requests from radio side port with the
access router's Ethernet MAC address so that all IPv4 packets from
SSs are forwarded to the access router.
6.2.2. Enterprise LAN Scenario Case
The bridge behind the BSs SHOULD maintain an ARP Cache large enough
to accommodate ARP entries for all its serving SSs. The ARP Cache
SHOULD be updated by any packets including ARP Requests from SSs in
the same way the bridge is updating its Filtering Database.
Upon receiving the ARP Requests from SSs, the bridge SHOULD unicast
ARP Replies back to SSs with Ethernet address of target host provided
that the target address matches an entry in the ARP Cache.
Otherwise, the bridge MAY flood the ARP Requests. The bridge SHOULD
silently discard any received self-ARP Requests.
7. Access Router Considerations
In the public access scenario, all packets between SSs will always be
relayed via access router. In this scenario, the access router
SHOULD forward packets via same interface on which the access router
received the packets, if source and destination addresses are
reachable on the same interface. This would result in a Redirect
message from the access router [RFC0792][I-D.ietf-ipv6-rfc2461bis].
The Redirect message SHOULD be suppressed.
Jeon, et al. Expires January 10, 2008 [Page 12]
Internet-Draft IPoEth over IEEE 802.16 July 2007
8. Prefix Assignment
8.1. Public Access Scenario Case
Unique IPv6 prefix per SS SHOULD be assigned because it results in
layer 3 separation between SSs and it forces all packets from SSs to
be transferred to an AR. The AR SHOULD assign the IPv6 prefixes with
Prefix Information option as specified in [RFC2461].
One IPv4 prefix SHOULD be assigned to all SSs in a way that it
benefits from high address assignment efficiency when concerning
scarce IPv4 address space. The prefix can be manually configured or
automatically with subnet mask option in DHCPv4 [RFC2132].
8.2. Enterprise LAN Scenario Case
The AR SHOULD assign all SSs one IPv4 prefix in IPv4 over Ethernet
and one or more IPv6 prefixes in IPv6 over Ethernet so that all SSs
under the same AR share the subnet prefix. Sharing the prefix means
locating all SSs on the same subnetwork.
9. Transmission of IP over Ethernet
9.1. IPv4 over Ethernet
[RFC0894] defines the transmission of IPv4 packets over Ethernet
networks. It contains the specification of the encapsulation of the
IPv4 packets into Ethernet frames as well as rules for mapping of IP
addresses onto Ethernet MAC addresses. IP over Ethernet over
IEEE802.16 MUST follow the operations specified in [RFC0894].
9.1.1. Address Configuration
IPv4 addresses can be configured manually or assigned dynamically
from DHCPv4 server [RFC2131].
DHCP clients may send DHCP DISCOVER and DHCP REQUEST messages with
the BROADCAST bit set to request the DHCP server to broadcast its
DHCP OFFER and DHCP ACK messages. The bridge SHOULD filter these
broadcast DHCP OFFER and DHCP ACK messages and forwards the broadcast
messages only to the host defined by the client hardware address in
the chaddr information element.
Alternatively, the DHCP Relay Agent Information Option (option-82)
[RFC3046] MAY be used to avoid DHCP broadcast replies. The option-82
consists of two type of sub-options; Circuit ID and Remote ID. DHCP
Relay Agent is usually located on bridges as Layer 2 DHCP Relay
Jeon, et al. Expires January 10, 2008 [Page 13]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Agent, like described in [TR101]. Bridge port number is possible as
Circuit ID and Remote ID may be left unspecified. Note that using
option-82 requires option-82 aware DHCP servers.
9.1.2. Address Resolution
SSs MUST use Address Resolution Protocol (ARP) [RFC0826] for finding
a destination's Ethernet MAC address.
9.2. IPv6 over Ethernet
[RFC2464] defines transmission of IPv6 Packets over Ethernet
Networks. In this document, encapsulation of IPv6 packets into
Ethernet frames and mapping rules for IPv6 address to Ethernet
address (i.e. MAC address) MUST follow [RFC2464].
9.2.1. Router Discovery, Prefix Discovery and Parameter Discovery
Router Discovery, Prefix Discovery and Parameter Discovery procedures
are achieved by receiving Router Advertisement messages. In this
specification, SSs perform above the discovery process by solicited
Router Advertisement messages because periodic Router Advertisement
messages are discarded on the bridges following the Broadcast Data
Forwarding Rules in Section 6.1.2.
9.2.2. Address Configuration
9.2.2.1. Stateful Address Autoconfiguration
When the'M' flag in the received RA is set, a SS SHOULD perform
stateful address configuration according to [RFC3315]. In this case,
an AR supports DHCPv6 server or relay function.
9.2.2.2. Stateless Address Autoconfiguration
SS SHOULD derive its global IPv6 addresses based on prefix and EUI-
64-derived interface identifier and then confirmed through Duplicate
Address Detection (DAD) as specified in [I-D.ietf-ipv6-rfc2462bis]
and [I-D.ietf-ipv6-rfc2461bis].
9.2.3. Address Resolution
SS SHOULD send Neighbor Solicitation destined for solicited-node
address corresponding to the target address in order to determine MAC
address of a neighbor and then resolve the MAC address by receiving
Neighbor Advertisement as specified in [I-D.ietf-ipv6-rfc2461bis].
Jeon, et al. Expires January 10, 2008 [Page 14]
Internet-Draft IPoEth over IEEE 802.16 July 2007
9.3. Maximum Transmission Unit Consideration
[RFC2460] requires that the link layer support a minimum Maximum
Transmission Unit (MTU) size of 1280 bytes and recommends a MTU size
of at least 1500 bytes for IPv6 over Ethernet transmission.
[RFC0894] also specifies 1500 bytes as a maximum length of IPv4 over
Ethernet. Therefore, IEEE 802.16 frame should carry a payload size
of 1518 bytes including the Ethernet header size of 18 bytes or 1522
bytes including additional VLAN tag size of 4 bytes if present.
The Length field in IEEE 802.16 MAC header has a size of 11 bits and
indicates length in bytes of the MAC PDU including CRC and MAC
header. Hence MAC PDU size is up to 2048 bytes and the maximum size
of payload is 2038 bytes by subtracting size of CRC and IEEE 802.16
MAC header from 2048 bytes. Since the size of MAC PDU is sufficient
to encapsulate an Ethernet packet carrying IP data size of 1500
bytes, the size of the largest IPv4 and IPv6 packets over Ethernet
over IEEE 802.16 SHOULD be 1500 bytes as specified in [RFC0894] and
[RFC2460] respectively.
10. Security Considerations
This document does not introduce new vulnerability to operations of
IPv4 over Ethernet and IPv6 over Ethernet. [RFC3971] can be adopted
for securing neighbor discovery processes.
11. Acknowledgments
The authors would like to thank David Johnston, Dave Thaler, and
others for their inputs to this work.
12. References
12.1. Normative References
[I-D.ietf-16ng-ps-goals]
Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-ietf-16ng-ps-goals-01 (work in progress),
February 2007.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
[I-D.ietf-ipv6-rfc2462bis]
Jeon, et al. Expires January 10, 2008 [Page 15]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Thomson, S., "IPv6 Stateless Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08 (work in progress),
May 2005.
[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]
IEEE P802.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", December 2005.
[IEEE802.16k]
IEEE 802.16's Network Management Task Group: 802.16k Pro
ject, "http://www.ieee802.org/netman/16k.html".
[IEEE802.1D]
IEEE Std 802.1D-2004, "IEEE Standard for Local and
metropolitan area networks, Media Access Control (MAC)
Bridges", June 2004.
[IEEE802.1Q]
IEEE Std 802.1Q-2005, "IEEE Standard for Local and
metropolitan area networks, Virtual Bridged Local Area
Networks", May 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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
Jeon, et al. Expires January 10, 2008 [Page 16]
Internet-Draft IPoEth over IEEE 802.16 July 2007
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
12.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation",
April 2006.
Appendix A. Multicast CID Deployment Considerations
IEEE 802.16 allows for downlink CIDs associated to multiple SSs to
support efficient transport of multicast and broadcast data. While
this looks in theory promising for solving the issue of the scarce
radio resource it introduces a number of issues in real deployments:
o Incompatibility with advanced radio layer algorithms based on
feedback information from the receiver: Many of the most advanced
algorithms for enhancing the capacity of radio links like HARQ,
Interference cancellation or MIMO are based on feedback from the
receiver side and do not work with multiple receivers on the same
CID.
o Incompatibility with advanced antenna systems: Advanced antenna
systems deploy multiphase antenna arrays to direct the
transmission to the particular receiver. Advanced antenna systems
work well with unicast links but the state of the art is not able
to support efficiently multicast links.
Jeon, et al. Expires January 10, 2008 [Page 17]
Internet-Draft IPoEth over IEEE 802.16 July 2007
o Increased interference level due to higher transmission power for
multicast links: Multicast links can not deploy advanced radio
layer algorithms like HARQ and therefore have to use higher
transmission power level to generate the signal to noise ratio
required for error-free detection. Higher transmission power also
increases the interference level in the cell as well as in
neighbor cells, which reduces the overall capacity of a cell.
o Reduced efficiency with mobile terminals: A multicast CID must be
configured to provide sufficient signal to noise ratio to the most
distant terminal. If terminals are moving, the radio transmission
characteristics may change and may require frequent re-adjustments
of the radio link parameters. As more moving terminals are
associated with a multicast CID as more likely the link conditions
require high reserves to keep all terminals permanently connected.
o Loss of power-down capabilities: Terminals associated to a
multicast CID have to wake up and decode the frames whenever
frames as send. This makes it difficult to keep terminals for
longer periods in low power consumption states.
o Increased complexity of the system: Each multicast CID requires
its own encryption key. This requires that SSs have to have the
capability to establish and maintain multiple encryption keys.
The BS requires for each of the multicast CIDs an instance of the
group key management system.
Taking the many drawbacks of multicast CIDs into account, the high
complexity and low transmission efficiency restricts the usability
for only exceptional cases when power consumption of SSs is no issue,
when SSs are hardly moving and when multicast CIDs are serving a high
number of SSs concurrently. All these conditions are hardly
fulfilled in today's mobile networking environment with small cell
sizes, fast moving terminals and a huge variety of information
sources which makes it unlikely that two users in a cell are
requesting concurrently the same information.
Jeon, et al. Expires January 10, 2008 [Page 18]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Authors' Addresses
HongSeok Jeon
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-3892
Email: hongseok.jeon@gmail.com
Max Riegel
Nokia Siemens Networks
St-Martin-Str 76
Munich, 81541
Germany
Phone: +49-89-636-75194
Email: maximilian.riegel@nsn.com
SangJin Jeong
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-1877
Email: sjjeong@gmail.com
Jeon, et al. Expires January 10, 2008 [Page 19]
Internet-Draft IPoEth over IEEE 802.16 July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jeon, et al. Expires January 10, 2008 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 04:35:27 |