Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
gabriel montenegro <g_e_montenegro@yahoo.com> Tue, 09 June 2009 16:48 UTC
Return-Path: <g_e_montenegro@yahoo.com>
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871FF28C10D for <16ng@core3.amsl.com>; Tue, 9 Jun 2009 09:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_63=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeHfLMowtLd3 for <16ng@core3.amsl.com>; Tue, 9 Jun 2009 09:48:45 -0700 (PDT)
Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 35ACE3A68FD for <16ng@ietf.org>; Tue, 9 Jun 2009 09:48:45 -0700 (PDT)
Received: (qmail 16301 invoked by uid 60001); 9 Jun 2009 16:48:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244566131; bh=l9dNUrVKeeUeCsXhQVzqWYsfN9NgqOnRHnlvczZz8Bc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xLiX3BtcIVF9jfzfeeQ3NiK/HOsgzS8tTtbMBa9oNfdMj9S1S2jJyGqqG0ojqieSiv+nGY+l9fwpiI9NjXuhsp7OdG4DRU71CpZGs8oXPv0FNECzWBbjAF+W2h/hsClKXeGGyrXMGhJg6Z2gIZRnWoqITAsr+uGmCbda0KsyHXo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JKy6BRkriSKQGsszaK4WfThvkqonnDuj0K2uk3TWoX5bpFiWkdxjTOuWxKUkqCGvb92MD41O6Z7X8KOockHIAMs/mJ0Cla1mpuE2T1r5RRZcW5YsnQvw+KxQNez7nd9knN+ZS3+2CpYSPqOmSyCoXl4McXcmVBTCfiwt1f46Qfc=;
Message-ID: <279552.13378.qm@web82601.mail.mud.yahoo.com>
X-YMail-OSG: SwB4aMEVM1lagQIgkzaPZQeJRmHrUBi.aRUNH2x5j1l8VsUa25DR_ALp9nAVIO2_YzRjqqZe1zDd_1053wHhDfuTCjBxuNSto4Ho7JNZZVFd24ZyUWPvDBYBDtnQT8bQslOZkgHDN4F1djq4hR2XnwNJ_iplQ.khF2XcIammgOW.3iiLtW0mpTi6Xp8Fkanv6NvDj9YyontATVI5cHhH3NupiNmF3kNgMgbEKI7op0U78Mz0HO7Irw5CmyiGzG.IJINI7aX2KKQZEdok1xg6pfeCs440MSa.ozbKObiiPWrZKKlQRR.bO96dCCTIXhy5Q_sfGLhvkRVJYZrDkdhuiLiYc2ytGPLi
Received: from [24.16.92.42] by web82601.mail.mud.yahoo.com via HTTP; Tue, 09 Jun 2009 09:48:47 PDT
X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10
References: <20090603154501.B0C963A6CBB@core3.amsl.com> <BC27158B99D3064A955ADE084783900C021E70E1@DEMUEXC014.nsn-intra.net> <BC27158B99D3064A955ADE084783900C021E70E2@DEMUEXC014.nsn-intra.net>
Date: Tue, 09 Jun 2009 09:48:47 -0700
From: gabriel montenegro <g_e_montenegro@yahoo.com>
To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>, 16ng@ietf.org
In-Reply-To: <BC27158B99D3064A955ADE084783900C021E70E2@DEMUEXC014.nsn-intra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ext Alper Yegin <alper.yegin@yegin.org>
Subject: Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 16:48:54 -0000
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@nsn.com> > To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>; 16ng@ietf.org > Cc: ext Alper Yegin <alper.yegin@yegin.org>; ext gabriel montenegro <g_e_montenegro@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@ietf.org [mailto:16ng-bounces@ietf.org] On Behalf Of > ext Riegel, Maximilian (NSN - DE/Munich) > Sent: Friday, June 05, 2009 12:50 AM > To: 16ng@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@gmail.com > > > > > > Soohong Daniel Park > > Samsung Electronics > > 416 Maetan-3dong, Yeongtong-gu > > Suwon 442-742 > > Korea > > > > Email: soohong.park@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@ipinfusion.com > > > > > > Gabriel Montenegro > > Microsoft Corporation > > Redmond, Washington > > USA > > > > Email: gabriel.montenegro@microsoft.com > >
- [16NG] I-D Action:draft-ietf-16ng-ipv4-over-802-d… Internet-Drafts
- Re: [16NG] I-D Action:draft-ietf-16ng-ipv4-over-8… Riegel, Maximilian (NSN - DE/Munich)
- Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-80… Riegel, Maximilian (NSN - DE/Munich)
- Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-80… gabriel montenegro
- Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-80… gabriel montenegro