Internet DRAFT - draft-mandin-ip-over-80216-ethcs

draft-mandin-ip-over-80216-ethcs






Network Working Group                                          J. Mandin
Internet-Draft                                                    Runcom
Expires: April 19, 2006                                 October 16, 2005


                      Transport of IP over 802.16
                draft-mandin-ip-over-80216-ethcs-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 April 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   In this memo we describe a simple scheme for configuration and
   provisioning of an 802.16 network so that it emulates a broadcast
   network that uses the 802.3 packet format.  We briefly describe how
   this network supports IPv4 and IPv6 services in a manner similar to
   other broadcast media (eg. ethernet).  Finally, we review some
   architectural issues behind the choice of broadcast network emulation
   and examine alternative approaches to supporting IP over 802.16.  We
   additionally describe some possible system optimizations to reduce
   consumption of air resources.



Mandin                   Expires April 19, 2006                 [Page 1]

Internet-Draft         Transport of IP over 802.16          October 2005


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . .  6
     4.1.  Transport Connections  . . . . . . . . . . . . . . . . . .  6
     4.2.  802.16 PDU format  . . . . . . . . . . . . . . . . . . . .  6
     4.3.  802.16 Convergence Sublayer  . . . . . . . . . . . . . . .  6
     4.4.  Convergence Sublayer Types . . . . . . . . . . . . . . . .  7
     4.5.  Payload Header Suppression . . . . . . . . . . . . . . . .  8
   5.  Supporting IPv4 and IPv6 over 802.16 via Broadcast Network
       Emulation  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Logical Topology of Simple Broadcast Network Emulation . .  9
     5.2.  IPv4 functions on the 802.16-based broadcast network . . . 10
   6.  Survey of possible alternative approaches  . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Deployment considerations for IPv4  . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16





























Mandin                   Expires April 19, 2006                 [Page 2]

Internet-Draft         Transport of IP over 802.16          October 2005


1.  Requirements notation

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














































Mandin                   Expires April 19, 2006                 [Page 3]

Internet-Draft         Transport of IP over 802.16          October 2005


2.  Introduction

   IEEE 802.16-2004 is a specification of the MAC and PHY layers for
   OFDM and OFDMA-based broadband wireless access.

   The point-to-multipoint topology of 802.16 raises some interesting
   questions about how to best support IPv4 and IPv6.  IEEE 802.16-2004
   describes several encapsulation schemes for carrying IP payload data,
   but does not provide a detailed description of how to support IP
   transport (and related services such as IP endpoint initialization
   and IP multicast).

   In this memo we describe a simple scheme for configuration and
   provisioning of an 802.16 network so that it emulates a broadcast
   network that uses the 802.3 packet format.  We briefly describe how
   this network supports IPv4 and IPv6 services in a manner similar to
   other broadcast media (eg. ethernet).  Finally, we review some
   architectural issues behind the choice of broadcast network emulation
   and examine alternative approaches to supporting IP over 802.16.  We
   additionally describe some possible system optimizations to reduce
   consumption of air resources.






























Mandin                   Expires April 19, 2006                 [Page 4]

Internet-Draft         Transport of IP over 802.16          October 2005


3.  Terminology

   BS - Base Station

   PHS - Payload Header Suppression

   PDU - Protocol Data Unit.  This refers to the data format passed from
   the lower edge of the 802.16 MAC to the 802.16 PHY, which typically
   contains SDU data after fragmentation, encryption, etc.

   SDU - Service Data Unit.  This refers to the data format passed to
   the upper edge of the 802.16 MAC

   SS - Subscriber Station





































Mandin                   Expires April 19, 2006                 [Page 5]

Internet-Draft         Transport of IP over 802.16          October 2005


4.  Overview of the IEEE 802.16-2004 MAC layer

   The topology of the IEEE 802.16-2004 network is point-to-multipoint
   (PMP): a Base Station (BS) communicates with a number of Subscriber
   Stations (SSes).  Each node in the network possesses a 48-bit MAC
   address (though in the Base Station this 48-bit unique identifier is
   called "BSId").  Each node possesses an x.509 certificate attesting
   to its MAC address/BSId.  The BS and SS learn each others' MAC
   Address/BSId during the SS's entry into the network.

4.1.  Transport Connections

   User data traffic (in both the BS-bound and SS-bound directions) is
   carried on unidirectional "transport connections".  Each transport
   connection has a particular set of associated parameters indicating
   characteristics such as cryptographic suite and quality-of-service.

   After successful entry of a SS to the 802.16 network, no data traffic
   is possible - as there are as yet no transport connections between
   the BS and SS.  Transport connections are established by a 3-message
   signalling sequence within the MAC layer (usually initiated by the
   BS).

   A downlink-direction transport connection is regarded as "multicast"
   if it has been made available (via MAC signaling) to more than one
   SS.  Uplink-direction connections are always unicast.

4.2.  802.16 PDU format

   An 802.16 PDU (ie. the format that is transmitted over the airlink)
   consists of a 6-byte MAC header, various optional subheaders, and a
   data payload.

   The 802.16 6-byte MAC header carries the Connection Identifer (CID)
   of the connection with which the PDU is associated.  We should
   observe that there is no source or destination address present in the
   raw 802.16 MAC header.

4.3.  802.16 Convergence Sublayer

   The 802.16 convergence sublayer (CS) is the component of the MAC that
   is responsible for assigning transmit-direction SDUs (originating
   from a higher layer application - eg. an IP stack at the BS or SS) to
   a specific outbound transport connection.

   The convergence sublayer maintains an ordered "classifier table".
   Each entry in the classifier table includes a classifier and a target
   CID.  A classifier, in turn, consists of a conjunction of one or more



Mandin                   Expires April 19, 2006                 [Page 6]

Internet-Draft         Transport of IP over 802.16          October 2005


   subclassifiers - where each subclassifier specifies a packet field
   (eg. the destination MAC address in an ethernet frame, or the TOS
   field of an IP datagram contained in an ethernet frame) together with
   a particular value or range of values for the field.

   To perform classification on an outbound SDU, the convergence
   sublayer proceeds from the first entry of the classifier table to the
   last, and evaluates the fields of the SDU for a match with the table
   entry's classifier When a match is found, the convergence sublayer
   associates the SDU with the target CID (for eventual transmission),
   and the remainder of the 802.16 MAC and PHY processing can take
   place.

   The convergence sublayer includes an important additional function:
   payload header suppression (see section 2.5).

4.4.  Convergence Sublayer Types

   802.16 defines numerous convergence sublayer types.  The "type" of
   the convergence sublayer determines the fields that may appear in
   classifiers eg.

   o  "802.3/Ethernet CS" permits classifiers that examine fields in
      802.3-style headers

   o  "IPv4-over-ethernet CS" permits classifiers that examine fields in
      ethernet headers as well as fields of IPv4 (and encapsulated TCP/
      UDP headers) that are encapsulated in 802.3-style frames

   o  "IPv6-over-ethernet CS" permits classifiers that examine fields in
      ethernet headers as well as fields of IPv6 (and encapsulated TCP/
      UDP headers) that are encapsulated in 802.3-style frames

   Other CS types include ATM and "raw" IPv4/IPv6.  An implementation of
   802.16 can support multiple CS types.

   We can observe that the CS type actually defines the type of data
   interface (eg. 802.3) that is presented by 802.16 to the higher layer
   application.

   We can also observe that the forwarding mechanism of 802.16 makes no
   distinction between assigning an outbound SDU to a particular
   destination, assigning it to a particular multicast group, and
   assigning it to a particular class of service - the mechanism is
   precisely the same in all these cases.






Mandin                   Expires April 19, 2006                 [Page 7]

Internet-Draft         Transport of IP over 802.16          October 2005


4.5.  Payload Header Suppression

   One or more rules for payload header suppression (PHS) may be
   optionally associated with an outbound connection.  A PHS rule
   includes:

   o  a bit mask and a corresponding bit pattern (typically
      corresponding to frequently recurring sequence of bytes in the
      "header portion" of the SDU payload - such as the 14 bytes of an
      802.3 header)

   o  a target "PHS index" (to be carried as the first byte of the
      PHS-ed SDU)

   In an example where there is a single PHS rule defined for a
   particular connection, the convergence sublayer (after determining
   that an SDU matches a particular entry in the classifier table),
   checks whether the SDU does in fact include the "suppressable"
   pattern indicated by the PHS rule.  To perform suppression, the
   convergence sublayer removes the suppressable pattern from the SDU
   and prepends the PHS Index before moving the SDU forward for the
   remainder of the MAC and PHY processing.

   The illustration below compares the format of the non-PHS-ed and
   PHS-ed SDU formats:


























Mandin                   Expires April 19, 2006                 [Page 8]

Internet-Draft         Transport of IP over 802.16          October 2005


5.  Supporting IPv4 and IPv6 over 802.16 via Broadcast Network Emulation

5.1.  Logical Topology of Simple Broadcast Network Emulation

   When properly configured and assisted by a simple bridging function,
   802.16 can emulate a simple broadcast network.  Specifically:

   o  The 802.16 network must be configured (ie. via network management)
      with transport connections using an appropriate choice from the
      802.3/ethernet CS types (eg.  "IPv4 over ethernet").  The
      transport connections must be configured to forward 802.3 frames
      so that:

      *  outbound frames from the BS that contain a particular unicast
         destination MAC address are forwarded on a transport connection
         to the SS that bears that specific MAC address

      *  outbound frames from the BS that contain a non-unicast
         destination MAC address are forwarded on a transport connection
         that is received by all SSes

      *  outbound frames from the SS are always forwarded on a
         particular transport connection to the BS

   o  The BS must include an additional functional entity above the BS
      MAC layer to perform MAC bridging (for example: in conformance
      with IEEE 802.1D and operating as a learning bridge)

   o  Optionally: The 802.16 network can be configured (ie. via network
      management) with a payload header suppression (PHS) rule for each
      connection - so as to eliminate the most common value for the 14-
      byte 802.3 header (ie. the one containing the MAC address of the
      SS, the MAC address of the access router, and 0x0800 ethertype).
      In this way, we cause the 14 bytes of 802.3 overhead to be
      replaced with a single byte of PHS overhead.

   Additionally, network management may configure more than one
   transport connection to/from a particular SS (ie. to support
   diffentiated classes of service) without impacting the basic
   behaviour of the broadcast network emulation.

   If future amendments to 802.16 were to include support for robust
   header compression (ROHC), then ROHC could be used instead of PHS (or
   perhaps in conjunction with it) to efficiently control both 802.3 and
   IP header overhead.






Mandin                   Expires April 19, 2006                 [Page 9]

Internet-Draft         Transport of IP over 802.16          October 2005


5.2.  IPv4 functions on the 802.16-based broadcast network

   If we consider an IPv4 subnet based on the broadcast network
   described above, we will expect a standard IP host stack on each of
   the SSes, and an access router either co-located with the BS or on a
   bridged or tunnelled network behind it.

   IPv4 functions over this network are straightforward:

   o  IP endpoint management messages (whether DHCP, Mobile IP, or what
      have you) are carried over default transport connections in the
      uplink direction and MAC-address based unicast transport
      connections in both the downlink directions

   o  Unicast IP traffic between the subscriber-side IP hosts and the
      access router is carried on default transport connections in the
      uplink direction and on MAC-address based unicast transport
      connections in both the downlink direction

   o  Subnet-wide broadcasts from the access router (such as ICMP router
      advertisements) are transmitted over the downlink multicast
      transport connection and received by all subscriber-side IP hosts

   o  IP multicast traffic from the access router will be carried over
      the downlink multicast transport connection, and can be received
      by subscriber-side IP hosts that are listening for MAC messages
      with the particular multicast MAC address

   o  Subscriber-originated broadcasts (eg.  ARP), and unicast or
      multicast datagrams to subnet peers are transmitted up to the BS
      and back down over the appropriate transport connection by the
      bridging function

   o  Subscriber-side IP hosts may receive ICMP-redirect from the access
      router and can begin to use a new access router.
















Mandin                   Expires April 19, 2006                [Page 10]

Internet-Draft         Transport of IP over 802.16          October 2005


6.  Survey of possible alternative approaches

   There are a few ways that the 802.16 PMP network can be represented
   in terms of "IP links" (or "IP subnets").

   Separating the PMP network into a series of IP point-to-point links
   is possible in 802.16 using PPPoE.  Using PPP directly is not
   feasible in 802.16 because there is no convergence sublayer that
   permits classification to transport connections based on fields in a
   PPP header.  As well, this approach does not make use of the downlink
   direction multicast capability.

   The NBMA model does not seem relevant to 802.16, as in NBMA networks
   - unlike 802.16 PMP - a direct unicast connection is available
   between network nodes.

   An alternative approach to broadcast network emulation involves the
   use of the "Raw IP" convergence sublayer.  Rather than suppressing or
   compressing the 802.3 header from transported SDUs on a 802.3-CS-
   based transport connection, this approach transports only IP
   datagrams - on "raw IP"-CS-based connections.  The identities of the
   L2 endpoints are then reconstructed at either end of the airlink
   based on the L3 information.  This approach is problematic however as
   it seems to be impossible to fully abandon the notion of explicit L2
   addresses - most notably in IPv6 neighbor discovery messages (which
   carry L2 addresses directly), but also in various IPv4 IP address
   management protocols such as DHCP and Mobile IP registrations.
























Mandin                   Expires April 19, 2006                [Page 11]

Internet-Draft         Transport of IP over 802.16          October 2005


7.  Security Considerations

   TBD
















































Mandin                   Expires April 19, 2006                [Page 12]

Internet-Draft         Transport of IP over 802.16          October 2005


8.  Acknowledgements

   Ideas in this memo have benefitted from discussion in the Ethernet CS
   subteam of the Wimax Forum Network Working Group (Byoung-Jo Kim, Dave
   Maez, Max Riegel, N. K. Shankaranarayanan).














































Mandin                   Expires April 19, 2006                [Page 13]

Internet-Draft         Transport of IP over 802.16          October 2005


Appendix A.  Deployment considerations for IPv4

   In a service provider deployment of 802.16, some changes from the
   subnet scheme described in section 3 will often be desirable.  Since
   these involve placement of functional elements outside of the 802.16
   network, we describe these in an annex:

   1.  Subscriber-side IP hosts are of course not in the control of the
       service provider, and might generate spurious broadcast messages
       (eg. printer announcements).  The classifier table at the SS can
       be configured by network management so as to drop these broadcast
       frames.

   2.  The service provider might require that all frames (including
       frames between IP hosts on the same subnet) traverse the access
       router (eg. for accounting purposes).  There are several ways to
       accomplish this in the context of the emulated broadcast network.
       The most simple approach is to co-locate the bridging function at
       the access router (so that all frames must reach the access
       router where they can be accounted for).  Alternatively, the
       bridging function at the BS could conform to RFC 925 (ARP-based
       bridging) rather than 802.1D (transparent bridging) - so that
       once again every frame will traverse the access router.

   3.  ARP broadcasts consume bandwidth on the airlink and are not
       always necessary.  A proxy ARP function at the BS can respond to
       subscriber side ARPs (thus preventing propagation over the
       multicast transport connection).  As well, a functional elements
       co-located at the BS, the access router, or somewhere in between
       can use snooped DHCP of snooped mobile IP information to avoid
       the need to issue of ARPs from the head-end side of the network.


9.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.














Mandin                   Expires April 19, 2006                [Page 14]

Internet-Draft         Transport of IP over 802.16          October 2005


Author's Address

   Jeff Mandin
   Runcom
   Ha-homa 2
   Rishon Lezion
   Israel

   Email: jeff@streetwaves-networks.com










































Mandin                   Expires April 19, 2006                [Page 15]

Internet-Draft         Transport of IP over 802.16          October 2005


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




Mandin                   Expires April 19, 2006                [Page 16]