Subject: [16NG] I-D Action:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt

From: [email-masked]
Date: Wed, 3 Jun 2009 08:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over IEEE 802.16 Networks Working Group of the IETF.

	Title           : Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
	Author(s)       : S. Madanapalli, et al.
	Filename        : draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
	Pages           : 14
	Date            : 2009-06-03

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
Packet CS enables the transport of IPv4 packets directly over the
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Jun 2009 00:50:09 +0200

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
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
> 
>    convergence sublayers for transmitting upper layer protocols.  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.

> Madanapalli, et al.       Expires April 4, 2009                 [Page
1]
> 
> Internet-Draft        IPv4 over IEEE 802.16's IP CS         October
2008
> 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,
>               <http://www.ietf.org/internet-drafts/
>               draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt>.
> 
>    [802_16REV2]
>               Johnston, D., "SDU MTU Capability Declaration",
>               March 2008, <http://www.ieee.org/16>.
> 
>    [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: [email-masked]
> 
> 
>    Soohong Daniel Park
>    Samsung Electronics
>    416 Maetan-3dong, Yeongtong-gu
>    Suwon 442-742
>    Korea
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 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: [email-masked]
> 
> 
>    Gabriel Montenegro
>    Microsoft Corporation
>    Redmond, Washington
>    USA
> 
>    Email: [email-masked]
> 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext [email-masked]
> Sent: Wednesday, June 03, 2009 5:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [16NG] I-D
Action:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
> 	Filename        :
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv4-over-802-dot-16
-ipcs-05.txt

---

From: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Jun 2009 00:58:26 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Riegel, Maximilian (NSN - DE/Munich)
Sent: Friday, June 05, 2009 12:50 AM
To: [email-masked]
Cc: ext Alper Yegin; ext gabriel montenegro
Subject: Re: [16NG]
I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt

Bye
Max

Madanapalli
Technologies
Park

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 9 Jun 2009 09:48:47 -0700 (PDT)

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)" <[email-masked]>
> To: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>; [email-masked]
> Cc: ext Alper Yegin <[email-masked]>; ext gabriel montenegro <[email-masked]>
> 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
> 
> -----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
> >    Internet-Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at any
> Meanwhile the IEEE802.16-2009 (was REV2) specification has been released.
> > 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.
> > 
> >    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
> >                Model . . . . . . . . . . . . . . . . . . . . . . . . 10
> >    Appendix B.  Sending and Receiving IPv4 Packets  . . . . . . . . . 10
> >    Appendix C.  WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 11
> >                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
> > 
> >    and MAC layers.  The MAC includes various convergence sublayers (CS)
> >    over the IP-specific part of the packet CS (referred to as "IPv4 CS"
> 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.
> >    IPv4 [RFC0791] packets over the IP CS of IEEE 802.16.  This document
>                                     ^IPv4 CS
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> >    perspective of the IPv6 link between the MS and access router (AR)).
> 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
> > 
> > 
> As [RFC5154] is outdated, I would propose to provide an updated section 3.3. as 
> part of the IPv4 CS document.
> 
> >    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)?
> 
> >    established between the AR and a BS based on 'per MS' or 'per service
> >    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:
> > 
> The previous text talks about service flows; why 'CID' is mentioned here?
> 
> How do the two statements fit together? How does IPv4 CS establish a p2p link?
> 
> > 
> >    In order to enable the sending and receiving of IPv4 packets between
> >    for IPv4 is indicated.  In step 6, an initial service flow is created
> 
> Initial service flow? [RFC5121] does not specifies further service flows.
> 
> What is the difference between a Proxy MIP client and a Simple IP client?
> >    IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the
> > Madanapalli, et al.      Expires April 4, 2009                [Page 4]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >                        0                  1
> >      Fragmentation Subheader, Packing subheader etc and special payload
> > Madanapalli, et al.      Expires April 4, 2009                [Page 5]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    if an MS transmits 1500-octet packets in a deployment with a smaller
> >    adequate usage of the network bandwidth and resources.  Accordingly,
> >      Some of the mechanisms available for the IPv4 CS host to find out
> >      [802_16REV2]) to (among other things) allow providing the Service
> >      configure the negotiated MTU size for the IPv4 CS link.  However,
> >    o  Configuration and negotiation of MTU size at the network layer by
> >    This document recommends that all future implementations of IPv4 and
> 
> Why 'future'?
> 
> >    two alternatives: 1) use the default MTU (1500 bytes) or 2) determine
> >    PPMTUD[RFC 4821].  However, the PMTU mechanism has inherent problems
> >    of packet loss due to ICMP messages not reaching the sender and IPv4
> >    care of the MTU size between the MS and its correspondent node across
> > Madanapalli, et al.      Expires April 4, 2009                [Page 6]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is
> >    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
> >    Although DHCP is the recommended method of address assignment, it is
> >    successful Mobile IP [RFC3344] registration.  In such situations, the
> >    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 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
> >    specification simply assumes that the multicast service is provided.
> >    How the multicast service is implemented in an IEEE 802.16 Packet CS
> >    The 'Next hop' IP address of the IP CS MS is always the IP address of
> > Madanapalli, et al.      Expires April 4, 2009                [Page 7]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    simulating multicast by generating multiple unicast messages are out
> >    of scope of this document.  For further considerations on the use of
> >    This document specifies transmission of IPv4 packets over IEEE 802.16
> >    working group members Burcak Beser, Wesley George, Max Riegel and DJ
> >    Johnston helped shape the MTU discussion for IPv4 CS link.  Thanks to
> > Madanapalli, et al.      Expires April 4, 2009                [Page 8]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > 9.  References
> > 
> >              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
> >              February 2008.
> > 
> >              802.16 Problem Statement and Goals", RFC 5154, April 2008.
> > 
> >    [RFC4968]  Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
> >    [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
> >              November 1990.
> > 
> >    [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
> > Madanapalli, et al.      Expires April 4, 2009                [Page 9]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >              August 2002.
> > 
> >              > >              draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt>.
> > 
> >    [802_16REV2]
> >              March 2008, .
> >              area networks, Part 16:Air Interface for fixed and Mobile
> >    Two different MSs using two different convergence sublayers (e.g. an
> >    communicate at data link layer and requires interworking at IP layer.
> >    the MS and AR.  All the packets originated at the MS always reach the
> > Madanapalli, et al.      Expires April 4, 2009                [Page 10]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    frames when the IPv4 CS is used.  IPv4 CS classifies the packet based
> >    It then tunnels the packet that has been received on a particular MAC
> >    interface from the AR, would be mapped to a particular CID using the
> >    receives DHCP requests so that it can relay the DHCP responses to the
> >    specified IPv4 CS support for transmission of IPv4 packets between MS
> >    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
> >    particularities of the authentication and network entry procedures),
> 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
> > 
> > 
> >    Although this document does not directly specify details of multicast
> >    While uplink connections from the MSs to the BS provide only unicast
> >    transmission from the BS to a single MS.  For all-node IP addresses,
> >    distributed to all active point-to-point connections by the AR or by
> >    the BS.  All-router multicast packets and any broadcast packets from
> >    performed between BS and AR (if they are not co-located) to determine
> >    setup and is out of scope of this document.  In order to save energy
> >    device side should be reduced.  Only DHCP, IGMP, Router advertisemnet
> > 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
> >

---

From: gabriel montenegro <[email-masked]>
Date: Sun, 14 Jun 2009 23:28:25 -0700 (PDT)

Thanks Max for your comments. Below please find our response. I've submitted a new draft 06 
modified per comments received from both Max and Wesley.

Thanks Max, my responses below marked with "gab>".
I've elided text on which there is no comment.
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.
gab> Thanks, will drop mention of it, and update the references to the new
version of .16. and drop 802.1Q CS (one more example of why saying too much
is worse than saying what is necessary).
...

>    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.
gab> IP CS is a term defined in RFC5154 so we *could* use it, but I agree that it is better to 
be explicit.
Have changed to IPv4 CS throughout.
                                     ^IPv4 CS
Which MTU, which address assignment? More concise wording would help.
gab> Changed it to: "...method for hosts using IPv4 CS."
And in the above paragraph on "scope of this specification" added this text
extracted from RFC5121 to the end of that sentence: "for hosts served by a 
network that utilizes the IEEE Std 802.16 air interface"
                                 ^IPv4 CS
What do you mean with this sentence?
gab> Not needed as there are details later on anyway. 
Deleted the last part starting with "whose operation...".
Please clarify 'MS'; according to IEEE802.16 it only covers PHY and MAC.
According to IEEE802.16 the MS is not a 'host'.
gab> Terminology here (as specified above) is as defined in 5154, which is more
informal. Added this text taken from RFC5121 (except for the last sentence, which
I added to hopefully address your concern.
gab> fixed.
>    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.
gab> You were looking at a preliminary version, I guess, as the draft already refers to 
802.16 (which we'll update to say "802.16-2009"). 
...
>    encapsulation of IP packets, see [RFC5121] section 4 and [RFC5154]
As [RFC5154] is outdated, I would propose to provide an updated section 3.3. as part of the IPv4 CS document.
gab> I  just dropping 5154 and replaced it by a reference to 802.16-2009. 
We will not fix 5154 as that is merely informational and was a statement valid at a given
point in time. More concerning might be if RFC5121 (a standards-track document) were
suddenly wrong. Is this the case? 
>    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)?
gab> "MS" here, in 5121 as well as in draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08 
(where there's mention of SS's sending ARP requests, tying to bridges, etc)
is a host, but I changed s/MS/host/
>    between between a BS and AR.  It is recommended that a tunnel be
                                                                   ^is
gab> I believe "be" is correct.
>    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.
gab> As in RFC5121, nothing in this respect is spelled out as it is not germane to the
issue of IP-over-foo from the host. We should not assume GRE, one could use a suite of other 
technologies, so mentioning GRE is not always correct nor necessary.
>    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.
gab> This detail about classification at the BS is in the appendix on
"Sending and Receiving IPv4 Packets".
gab> Have replaced the text above with text taken from 5121 for this same 
description.
The previous text talks about service flows; why 'CID' is mentioned here?
gab> Good point, changed to service flow here as well as an instance above.
How do the two statements fit together? How does IPv4 CS establish a p2p link?
gab> I've deleted this (as the new text is enough).
Initial service flow? [RFC5121] does not specifies further service flows.
gab> RFC5121 step 6 does talk about establishment of a "service flow" (no
mention of it being "initial"). Deleted "initial". RFC5121 talks about
an "initial service flow" and ISF in the appendix, however.
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?
gab> I've deleted this paragraph. An IP-over-foo document does not talk about potential
other uses with Mobile IP or any other such application, only about the most
essential business of transmitting and receiving packets on that link.
I've deleted all mention of Mobile IP as well as the reference to RFC3344.
...
'is configurable'?? How, by which means??
gab> There are several means to change it including manual, DHCP option, etc. 
Added this in parentheses to clarify: (e.g., see the bottom of this section for some possible
mechanisms). 
>       link SHOULD be 1500 octets.
...
gab> done.
>    This document recommends that all future implementations of IPv4 and
Why 'future'?
gab> changed it: s/all future//
>    the MTU by the methods described in [802_16REV2].
Can MS rely on the IEEE802.16 methods? Mandatory for all IEEE802.16 implementations?
gab> It cannot, just like it cannot rely on the other mentioned mitigations 
(DHCP option) and that is why the IPv4 situation is sub-optimal with respect to
IPv6.
>    different flavors of convergence layers in the access networks.
...
IEEE802.16-2009 is released and supersedes 16e as well as REV2.
Why is the IEEE802.16 specification listed under informative?
gab> 802.16-2009 is now the *only* reference to 802.16, and moved to normative.

...
 
> Appendix B.  Sending and Receiving IPv4 Packets
...
>    address and Tunnel Identifier.
Which MAC address?
gab> The assumption is that is the MAC address contained in the DHCP request.
Another method would be to keep a correspondence between DHCP Transaction ID
and the incoming Tunnel ID. At any rate, this is not specific to 802.16, so 
I replaced the last sentence with:
"The particular method is out of scope of this specification
as it need not depend on any particularities of IEEE 802.16."
Appendix C should be removed.
Only WiMAX devices will enter WiMAX networks, and WiMAX devices know about the MTU size in WiMAX networks.
gab> That is actually said right above, so you might agree it is useful info (since
you noted it yourself). The text above was already changed per your request to *NOT*
issue any recommendation to WiMAX (even though per charter that would be ok). 
I don't see the harm and see some benefit in keeping it as informative text.

----- Original Message ----
> From: gabriel montenegro <[email-masked]>
> Cc: ext Alper Yegin <[email-masked]>
> Sent: Tuesday, June 9, 2009 9:48:47 AM
> > From: "Riegel, Maximilian (NSN - DE/Munich)" 
> > To: "Riegel, Maximilian (NSN - DE/Munich)" ; 
> [email-masked]
> > Cc: ext Alper Yegin ; ext gabriel montenegro 
> 
> > >              > >              
> _______________________________________________
> 16NG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/16ng