[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
Thanks Max, the attached version is better! I'm still going through the comments.
Will respond later on.
----- Original Message ----
> From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel at nsn.com>
> To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel at nsn.com>; 16ng at ietf.org
> Cc: ext Alper Yegin <alper.yegin at yegin.org>; ext gabriel montenegro <g_e_montenegro at yahoo.com>
> Sent: Thursday, June 4, 2009 3:58:26 PM
> Subject: Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
>
> Please find attached the txt document with my comments, in the case your
> screen looks as awful as mine (word wrapping did a horrible job)
>
> Bye
> Max
>
> -----Original Message-----
> From: 16ng-bounces at ietf.org [mailto:16ng-bounces at ietf.org] On Behalf Of
> ext Riegel, Maximilian (NSN - DE/Munich)
> Sent: Friday, June 05, 2009 12:50 AM
> To: 16ng at ietf.org
> Cc: ext Alper Yegin; ext gabriel montenegro
> Subject: Re: [16NG]
> I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
>
> I went through the document and found a couple of issues, which I would
> like to see in a better shape.
> Please find my comments inline:
>
> Bye
> Max
>
> > 16ng Working Group S.
> Madanapalli
> > Internet-Draft Ordyn
> Technologies
> > Intended status: Standards Track Soohong D.
> Park
> > Expires: April 4, 2009 Samsung
>
>
>
> -----Inline Attachment Follows-----
>
> > 16ng Working Group S. Madanapalli
> > Internet-Draft Ordyn Technologies
> > Intended status: Standards Track Soohong D. Park
> > Expires: April 4, 2009 Samsung Electronics
> > S. Chakrabarti
> > IP Infusion
> > G. Montenegro
> > Microsoft Corporation
> > October 2008
> >
> >
> > Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
> > draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.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 4, 2009.
> >
> > Abstract
> >
> > IEEE 802.16 is an air interface specification for wireless broadband
> > access. IEEE 802.16 has specified multiple service specific
> > convergence sublayers for transmitting upper layer protocols. The
> > packet CS (Packet Convergence Sublayer) is used for the transport of
> > all packet-based protocols such as Internet Protocol (IP), IEEE 802.3
> > (Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the
>
> Meanwhile the IEEE802.16-2009 (was REV2) specification has been released.
> IEEE802.16-2009 does not know anymore about the IEEE 802.1Q (VLAN) CS.
>
> > Packet CS enables the transport of IPv4 packets directly over the
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 1]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > IEEE 802.16 MAC.
> >
> > This document specifies the frame format, the Maximum Transmission
> > Unit (MTU) and address assignment procedures for transmitting IPv4
> > packets over the IP-specific part of the Packet Convergence Sublayer
> > of IEEE 802.16.
> >
> >
> > Table of Contents
> >
> > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
> > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
> > 3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 3
> > 3.1. IEEE 802.16 IPv4 Convergence sub-layer support . . . . . . 3
> > 4. IPv4 CS link in 802.16 Networks . . . . . . . . . . . . . . . 4
> > 4.1. IPv4 CS link establishment . . . . . . . . . . . . . . . . 4
> > 4.2. Frame Format for IPv4 Packets . . . . . . . . . . . . . . 4
> > 4.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5
> > 5. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 7
> > 5.1. IPv4 Unicast Address Assignment and Router Discovery . . . 7
> > 5.2. Address Resolution Protocol . . . . . . . . . . . . . . . 8
> > 5.3. IP Multicast Address Mapping . . . . . . . . . . . . . . . 8
> > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
> > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
> > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
> > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
> > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
> > 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
> > Appendix A. Multiple Convergence Layers - Impact on Subnet
> > Model . . . . . . . . . . . . . . . . . . . . . . . . 10
> > Appendix B. Sending and Receiving IPv4 Packets . . . . . . . . . 10
> > Appendix C. WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 11
> > Appendix D. Thoughts on handling multicast-broadcast IP
> > packets . . . . . . . . . . . . . . . . . . . . . . . 12
> > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
> > Intellectual Property and Copyright Statements . . . . . . . . . . 14
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 2]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > 1. Introduction
> >
> > IEEE 802.16 [IEEE802_16] is a connection oriented access technology
> > for the last mile. The IEEE 802.16 specification includes the PHY
> > and MAC layers. The MAC includes various convergence sublayers (CS)
> > for transmitting higher layer packets including IPv4 packets
> > [RFC5154].
> >
> > The scope of this specification is limited to the operation of IPv4
> > over the IP-specific part of the packet CS (referred to as "IPv4 CS"
> > or simply "IP CS" in this document).
>
> IPv4 CS should be used throughout the document to prevent mixing it up with the
> IPv6 CS specification. There is nothing like IP CS in the IEEE802.16
> specification, there is only IPv4 CS and IPv6 CS.
> BTW: there is now a single ETH CS carrying IPv4 as well as IPv6 payload.
>
> > This document specifies a method for encapsulating and transmitting
> > IPv4 [RFC0791] packets over the IP CS of IEEE 802.16. This document
> ^IPv4 CS
> > also specifies the MTU and address assignment method for the IEEE
>
> Which MTU, which address assignment? More concise wording would help.
>
> > 802.16 based networks using IP CS.
> ^IPv4 CS
> >
> > This document also discusses ARP (Address Resolution Protocol) and
> > Multicast Address Mapping whose operation is similar to any other
> > point-to-point link model.
>
> What do you mean with this sentence?
>
> > 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].
> >
> >
> > 2. Terminology
> >
> > The terminology in this document is based on the definitions in
> > [RFC5154].
> >
> >
> > 3. Typical Network Architecture for IPv4 over IEEE 802.16
> >
> > The network architecture follows what is described in [RFC5154] and
> > [RFC5121]. In a nutshell, each MS is attached to an Access Router
>
> Please clarify 'MS'; according to IEEE802.16 it only covers PHY and MAC.
> According to IEEE802.16 the MS is not a 'host'.
>
> > (AR) through a Base Station (BS), a layer 2 entity (from the
> > perspective of the IPv6 link between the MS and access router (AR)).
> ^IPv4??? Copy&Paste mistake?
> >
> > For further information on the typical network architecture, see
> > [RFC5121] section 5.
> >
> > 3.1. IEEE 802.16 IPv4 Convergence sub-layer support
> >
> > As described in [RFC5154] section 3.3., an IP specific subpart
> > classifier carries either IPv4 or IPv6 payloads. In this document,
> > we are focusing on the IPv4 over IP Convergence Sublayer.
>
> Section 3.3 of [RFC5154] is outdated! IEEE802.16-2009 introduced a refined CS
> structure. IMHO, we shouldn't make references to outdated specifications, but
> base the work on the most recent IEEE802.16 specification.
>
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 3]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > For further information on the IEEE 802.16 Convergence Sublayer and
> > encapsulation of IP packets, see [RFC5121] section 4 and [RFC5154]
> > section 3.3.
>
> As [RFC5154] is outdated, I would propose to provide an updated section 3.3. as
> part of the IPv4 CS document.
>
> > 4. IPv4 CS link in 802.16 Networks
> >
> > This document defines the IPv4 CS link as a point-to-point link
> > between the MS and the AR using a set of service flows consisting of
>
> MS is not the host. What is a link between a L2 device (MS) and a L3 device
> (AR)?
>
> > MAC transport connections between a MS and BS, and L2 tunnel(s)
> > between between a BS and AR. It is recommended that a tunnel be
> ^is
> > established between the AR and a BS based on 'per MS' or 'per service
> > flow' (An MS can have multiple service flows each of which are
>
> What is a tunnel between BS and AR based on 'per MS'? It seems, some GRE
> functionality is assumed here without spelling it out.
>
> > identified by a unique service flow ID). Then the tunnel(s) for an
> > MS, in combination with the MS's MAC transport connections, forms a
> > single point-to-point link. Each MS belongs to a different link and
>
> How does this work - multiple tunnels between two endpoints forming a single
> link? I would assume, that there must be some classification in place, which is
> part of the BS according to IEEE802.16, not part of the AR, like the authors
> assume in the sentence.
>
> > is assigned an unique IPv4 address per recommendations in [RFC4968].
> >
> > To summarize:
> >
> > o IPv4 CS uses the IPv4 header fields to classify the packets and
> > map to the appropriate CID.
>
> The previous text talks about service flows; why 'CID' is mentioned here?
>
> > o A point-to-point link between MS and AR is established.
>
> How do the two statements fit together? How does IPv4 CS establish a p2p link?
>
> >
> > 4.1. IPv4 CS link establishment
> >
> > In order to enable the sending and receiving of IPv4 packets between
> > the MS and the AR, the link between the MS and the AR via the BS
> > needs to be established. This section explains the link
> > establishment procedures following section 6.2 of [RFC5121]. Steps
> > 1-4 are same as indicated in 6.2 of [RFC5121]. In step 5, support
> > for IPv4 is indicated. In step 6, an initial service flow is created
>
> Initial service flow? [RFC5121] does not specifies further service flows.
>
> > that can be used for exchanging IP layer signaling messages, e.g.
> > address assignment procedures using DHCP.
> >
> > The address assignment procedure depends on the MS mode - i,e.
> > whether it is acting as a Mobile IPv4 client or a Proxy Mobile IP
> > client or a Simple IP client. In the most common case, the MS
> > requests an IP address using DHCP.
>
> What is the difference between a Proxy MIP client and a Simple IP client?
> Does the 'MS' request an IP address by DHCP in the case of Client-MIP?
>
> >
> > 4.2. Frame Format for IPv4 Packets
> >
> > IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the
> > data payloads of the 802.16 PDU ( see section 3.2 of [RFC5154] ).
> >
> >
> >
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 4]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > 0 1
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |H|E| TYPE |R|C|EKS|R|LEN |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | LEN LSB | CID MSB |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | CID LSB | HCS |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | IPv4 |
> > +- -+
> > | header |
> > +- -+
> > | and |
> > +- -+
> > / payload /
> > +- -+
> > | |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |CRC (optional) |
> > +-+-+-+-+-+-+-+-+
> >
> >
> > Figure 1: IEEE 802.16 MAC Frame Format for IPv4 Packets
> >
> > H: Header Type (1 bit). Shall be set to zero indicating that it
> > is a Generic MAC PDU.
> > E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
> > is encrypted.
> > R: Reserved. Shall be set to zero.
> > C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
> > EKS: Encryption Key Sequence
> > LEN: The Length in bytes of the MAC PDU including the MAC header
> > and the CRC if present (11 bits)
> > CID: Connection Identifier (16 bits)
> > HCS: Header Check Sequence (8 bits)
> > CRC: An optional 8-bit field. CRC appended to the PDU after
> > encryption.
> > TYPE: This field indicates the subheaders (Mesh subheader,
> > Fragmentation Subheader, Packing subheader etc and special payload
> > types (ARQ) present in the message payload
> >
> > 4.3. Maximum Transmission Unit
> >
> > The MTU value for IPv4 packets on an IEEE 802.16 link is
> > configurable. The default MTU for IPv4 packets over an IEEE 802.16
>
> 'is configurable'?? How, by which means??
>
> > link SHOULD be 1500 octets.
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 5]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > Per [RFC5121] section 6.3, the IP MTU can vary to be larger or
> > smaller than 1500 octets.
> >
> > if an MS transmits 1500-octet packets in a deployment with a smaller
> > MTU, packets from the MS may be dropped at the link-layer silently.
> > Unlike IPv6, in which departures from the default MTU are readily
> > advertised via the MTU option in Neighbor Discovery, there is no
> > similarly reliable mechanism in IPv4, as the legacy IPv4 client
> > implementations do not determine the link MTU by default before
> > sending packets. Even though there is a DHCP option to accomplish
> > this, DHCP servers are required to provide the MTU information only
> > when requested.
> >
> > Discovery and configuration of the proper link MTU value ensures
> > adequate usage of the network bandwidth and resources. Accordingly,
> > deployments should avoid packet loss due to a mismatch between the
> > default MTU and the configured link MTUs.
> >
> > Some of the mechanisms available for the IPv4 CS host to find out
> > the link's MTU value and mitigate MTU-related issues are:
> >
> > o The IEEE is currently revising 802.16 (see 802.16Rev2
>
> IEEE802.16 has revised the specification. Update the reference.
>
> > [802_16REV2]) to (among other things) allow providing the Service
> > Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase,
> > such that future IEEE 802.16 compliant clients can infer and
> > configure the negotiated MTU size for the IPv4 CS link. However,
> > the implementation must communicate the negotiated MTU value to
> > the IP layer to adjust the IP Maximum payload size for proper
> > handling of fragmentation. Note that this method is useful only
> > when MS is directly connected to the BS.
> > o Configuration and negotiation of MTU size at the network layer by
> > using the DHCP interface MTU option [RFC2132].
> >
> > This document recommends that all future implementations of IPv4 and
>
> Why 'future'?
>
> > IPv4 CS clients SHOULD implement the DHCP interface MTU option
> > [RFC2132] in order to configure its interface MTU accordingly.
> >
> > In the absence of DHCP MTU configuration, the client node (MS) has
> > two alternatives: 1) use the default MTU (1500 bytes) or 2) determine
> > the MTU by the methods described in [802_16REV2].
>
> Can MS rely on the IEEE802.16 methods? Mandatory for all IEEE802.16
> implementations?
>
> > Additionally, the clients are encouraged to run PMTU[RFC 1191] or
> > PPMTUD[RFC 4821]. However, the PMTU mechanism has inherent problems
> > of packet loss due to ICMP messages not reaching the sender and IPv4
> > routers not fragmenting the packets due to the DF bit being set in
> > the IP packet. The above mentioned path MTU mechanisms will take
> > care of the MTU size between the MS and its correspondent node across
> > different flavors of convergence layers in the access networks.
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 6]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > 5. Subnet Model and IPv4 Address Assignment
> >
> > The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is
> > based on the point-to-point link between MS and AR [RFC4968], hence
> > each MS shall be assigned an address with 32bit prefix-length or
> > subnet-mask. The point-to-point link between MS and AR is achieved
> > using a set of IEEE 802.16 MAC connections (identified by CIDs) and
> > an L2 tunnel (e.g., a GRE tunnel) per MS between BS and AR. If the
> > AR is co-located with the BS, then the set of IEEE 802.16 MAC
> > connections between the MS and BS/AR represent the point-to- point
> > connection.
> >
> > 5.1. IPv4 Unicast Address Assignment and Router Discovery
> >
> > DHCP [RFC2131] SHOULD be used for assigning IPv4 address for the MS.
> > DHCP messages are transported over the IEEE 802.16 MAC connection to
> > and from the BS and relayed to the AR. In case the DHCP server does
> > not reside in the AR, the AR SHOULD implement DHCP relay Agent
> > [RFC1542].
> >
> > Although DHCP is the recommended method of address assignment, it is
> > possible that the MS could be a pure Mobile IPv4 [RFC3344] device
> > which will be offered an IP address from its home network after
> > successful Mobile IP [RFC3344] registration. In such situations, the
> > mobile host SHOULD use the default link MTU in order to avoid any
> > link-layer packet loss due to larger than supported packet size in
> > the IP CS link.
> >
> > Router discovery messages [RFC1256] contain router solicitation and
> > router advertisements. The Router solicitation messages (multicast
> > or broadcast) from the MS are delivered to the AR via the BS through
> > the point-to-point link. The BS SHOULD map the all-routers multicast
> > nodes or broadcast nodes for router discovery to the AR's IP address
> > and deliver directly to the AR. Similarly a router advertisement to
> > the all-nodes multicast nodes will be either unicast to each MS by
> > the BS separately or put onto a multicast connection to which all MSs
> > are listening to. If no multicast connection exists, and the BS does
> > not have the capability to aggregate and disaggregate the messages to
> > and from the MS hosts, then the AR implementation must ensure that
> > unicast messages are sent to the corresponding individual MS hosts
> > within the set of broadcast or multicast recipients. This
> > specification simply assumes that the multicast service is provided.
> > How the multicast service is implemented in an IEEE 802.16 Packet CS
> > deployment is out of scope of this document.
> >
> > The 'Next hop' IP address of the IP CS MS is always the IP address of
> > the AR, because MS and AR are attached via a point-to-point link.
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 7]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > 5.2. Address Resolution Protocol
> >
> > The IP CS does not allow for transmission of ARP [RFC0826] packets.
> > Furthermore, in a point-to-point link model, address resolution is
> > not needed.
> >
> > 5.3. IP Multicast Address Mapping
> >
> > IPv4 multicast packets are carried over the point-to-point link
> > between the AR and the MS (via the BS). The IPv4 multicast packets
> > are classified normally at the IP CS if the IEEE 802.16 MAC
> > connection has been set up with a multicast IP address as a
> > classification parameter for the destination IP address. The IPv4
> > multicast address may be mapped into a multicast CID as defined in
> > the IEEE 802.16 specification. The mapping mechanism at the BS or
> > the relative efficiency of using a multicast CID as opposed to
> > simulating multicast by generating multiple unicast messages are out
> > of scope of this document. For further considerations on the use of
> > multicast CIDs see [ETHCS].
> >
> >
> > 6. Security Considerations
> >
> > This document specifies transmission of IPv4 packets over IEEE 802.16
> > networks with IPv4 Convergence Sublayer and does not introduce any
> > new vulnerabilities to IPv4 specifications or operation. The
> > security of the IEEE 802.16 air interface is the subject of
> > [IEEE802_16]. In addition, the security issues of the network
> > architecture spanning beyond the IEEE 802.16 base stations is the
> > subject of the documents defining such architectures, such as WiMAX
> > Network Architecture [WMF].
> >
> >
> > 7. IANA Considerations
> >
> > This document has no actions for IANA.
> >
> >
> > 8. Acknowledgements
> >
> > The authors would like to acknowledge the contributions of Bernard
> > Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil,
> > Paolo Narvaez, and Bruno Sousa for their review and comments. The
> > working group members Burcak Beser, Wesley George, Max Riegel and DJ
> > Johnston helped shape the MTU discussion for IPv4 CS link. Thanks to
> > many other members of the 16ng working group who commented on this
> > document to make it better.
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 8]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > 9. References
> >
> > 9.1. Normative References
> >
> > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> > Requirement Levels", BCP 14, RFC 2119, March 1997.
> >
> > [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
> > September 1981.
> >
> > [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.
> >
> > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
> > RFC 2131, March 1997.
> >
> > [RFC1542] Wimer, W., "Clarifications and Extensions for the
> > Bootstrap Protocol", RFC 1542, October 1993.
> >
> > [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
> > Madanapalli, "Transmission of IPv6 via the IPv6
> > Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
> > February 2008.
> >
> > [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
> > 802.16 Problem Statement and Goals", RFC 5154, April 2008.
> >
> > [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
> > Based Networks", RFC 4968, August 2007.
> >
> > 9.2. Informative References
> >
> > [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
> > November 1990.
> >
> > [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
> > Discovery", RFC 4821, March 2007.
> >
> > [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
> > Extensions", RFC 2132, March 1997.
> >
> > [RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
> > Encapsulation Methods Considered Harmful", RFC 4840,
> > April 2007.
> >
> > [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 9]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > August 2002.
> >
> > [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
> > September 1991.
> >
> > [ETHCS] Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP
> > over Ethernet over IEEE 802.16 Networks", April 2008,
> > > > draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt>.
> >
> > [802_16REV2]
> > Johnston, D., "SDU MTU Capability Declaration",
> > March 2008, .
> >
> > [IEEE802_16]
> > "IEEE 802.16e, IEEE standard for Local and metropolitan
> > area networks, Part 16:Air Interface for fixed and Mobile
> > broadband wireless access systems", October 2005.
>
> IEEE802.16-2009 is released and supersedes 16e as well as REV2.
> Why is the IEEE802.16 specification listed under informative?
>
> > [WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3
> > Release 1.2,
> > http://www.wimaxforum.org/technology/documents";,
> > January 2008.
> >
> >
> > Appendix A. Multiple Convergence Layers - Impact on Subnet Model
> >
> > Two different MSs using two different convergence sublayers (e.g. an
> > MS using Ethernet CS only and another MS using IP CS only) cannot
> > communicate at data link layer and requires interworking at IP layer.
> > For this reason, these two nodes must be configured to be on two
> > different subnets. For more information refer to [RFC4840].
> >
> >
> > Appendix B. Sending and Receiving IPv4 Packets
> >
> > IEEE 802.16 MAC is a point-to-multipoint connection oriented air-
> > interface, and the process of sending and receiving of IPv4 packets
> > is different from multicast-capable shared medium technologies like
> > Ethernet.
> >
> > Before any packets are transmitted, a IEEE 802.16 transport
> > connection must be established. This connection consists of IEEE
> > 802.16 MAC transport connection between MS and BS and an L2 tunnel
> > between BS and AR (if these two are not co-located). This IEEE
> > 802.16 transport connection provides a point-to-point link between
> > the MS and AR. All the packets originated at the MS always reach the
> > AR before being transmitted to the final destination.
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 10]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > IPv4 packets are carried directly in the payload of IEEE 802.16
> > frames when the IPv4 CS is used. IPv4 CS classifies the packet based
> > on upper layer (IP and transport layers) header fields to place the
> > packet on one of the available connections identified by the CID.
> > The classifiers for the IPv4 CS are source and destination IPv4
> > addresses, source and destinations ports, Type-of-Service and IP
> > protocol field. The CS may employ Packet Header Suppression (PHS)
> > after the classification.
> >
> > The BS optionally reconstructs the payload header if PHS is in use.
> > It then tunnels the packet that has been received on a particular MAC
> > connection to the AR. Similarly the packets received on a tunnel
> > interface from the AR, would be mapped to a particular CID using the
> > IPv4 classification mechanism.
> >
> > AR performs normal routing for the packets that it receives,
> > processing them per its forwarding table. However, the DHCP relay
> > agent in the AR MUST maintain the tunnel interface on which it
> > receives DHCP requests so that it can relay the DHCP responses to the
> > correct MS. One way of doing this is to have a mapping between MAC
> > address and Tunnel Identifier.
>
> Which MAC address?
>
> >
> > Appendix C. WiMAX IPCS MTU size
> >
> > WiMAX (Worldwide Interoperability for Microwave Access) forum has
> > defined a network architecture[WMF]. Furthermore, WiMAX has
> > specified IPv4 CS support for transmission of IPv4 packets between MS
> > and BS over the IEEE 802.16 link. The WiMAX IPv4 CS and this
> > specification are similar. One significant difference, however, is
> > that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets
> > [WMF] as opposed to 1500 in this specification.
> >
> > Hence if an IPv4 CS MS configured with an MTU of 1500 octet enters a
> > WiMAX network, some of the issues mentioned in this specification may
> > arise. As mentioned in section 4.3, the possible mechanisms are not
> > guaranteed to work. Furthermore, an IPv4 CS client is not capable of
> > doing ARP probing to find out the link MTU. On the other hand, it is
> > imperative for an MS to know the link MTU size. In practice, MS
> > should be able to sense or deduce the fact that they are operating
> > within a WiMAX network (e.g., given the WiMAX-specific
> > particularities of the authentication and network entry procedures),
> > and adjust their MTU size accordingly. This document makes no
> > further assumptions in this respect.
>
> Appendix C should be removed.
> Only WiMAX devices will enter WiMAX networks, and WiMAX devices know about the
> MTU size in WiMAX networks.
>
> >
> >
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 11]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > Appendix D. Thoughts on handling multicast-broadcast IP packets
> >
> > Although this document does not directly specify details of multicast
> > or broadcast packet handling, here are some suggestions:
> >
> > While uplink connections from the MSs to the BS provide only unicast
> > transmission capabilities, downlink connections can be used for
> > multicast transmission to a group of MSs as well as unicast
> > transmission from the BS to a single MS. For all-node IP addresses,
> > the AR or BS should have special mapping and the packets should be
> > distributed to all active point-to-point connections by the AR or by
> > the BS. All-router multicast packets and any broadcast packets from
> > a MS will be forwarded to the AR by the BS. If BS and MS are co-
> > located, then the first approach is more useful. If the AR and BS
> > are located separately then the second approach should be
> > implemented. An initial capability exchange message should be
> > performed between BS and AR (if they are not co-located) to determine
> > who would perform the distribution of multicast/broadcast packets.
> > Such mechansim should be part of L2 exchange during the connection
> > setup and is out of scope of this document. In order to save energy
> > of the wireless end devices in the IEEE 802.16 wireless network, it
> > is recommened that the multicast and broadcast from network side to
> > device side should be reduced. Only DHCP, IGMP, Router advertisemnet
> > packets are allowed on the downlink for multicast and broadcast IP
> > addresses. Other protocols using multicast and broadcast IP
> > addresses should be permitted through local AR/BS configuration.
> >
> >
> > Authors' Addresses
> >
> > Syam Madanapalli
> > Ordyn Technologies
> > 1st Floor, Creator Building, ITPL
> > Bangalore - 560066
> > India
> >
> > Email: smadanapalli at gmail.com
> >
> >
> > Soohong Daniel Park
> > Samsung Electronics
> > 416 Maetan-3dong, Yeongtong-gu
> > Suwon 442-742
> > Korea
> >
> > Email: soohong.park at samsung.com
> >
> >
> >
> >
> >
> > Madanapalli, et al. Expires April 4, 2009 [Page 12]
> >
> > Internet-Draft IPv4 over IEEE 802.16's IP CS October 2008
> >
> >
> > Samita Chakrabarti
> > IP Infusion
> > 1188 Arques Avenue
> > Sunnyvale, CA
> > USA
> >
> > Email: samitac at ipinfusion.com
> >
> >
> > Gabriel Montenegro
> > Microsoft Corporation
> > Redmond, Washington
> > USA
> >
> > Email: gabriel.montenegro at microsoft.com
> >