Hi Sri, > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Tuesday, September 23, 2014 4:06 PM > To: Templin, Fred L; [email protected] > Subject: Re: Signaling Message Fragmentation > > Hi Fred, > > Thanks for your response and also sorry for the delay in catching up on > this thread; Had to focus on some other business. > > The issue that I raised is specifically in the context of control plane > messages. Some of the mobility options (Ex: Dynamic Mobile Network Prefix > option in RFC7148) can easily exceed the path MTU size. Each of these > options by itself may not be huge, but multiple instances of the option > can be included in the message. For Mobile Networks use-case, its possible > a mobile node is assigned a set of IPv6 prefixes and based on the count > exceed the MTU limits. As such this should be OK; But ensuring > fragmentation in the MIP layer eliminates issues such as dropped fragments > by mid-level boxes and also fragmentation by on-path nodes. The question > is also not about requiring a huge buffer sizes, but more about handling > messages which are slightly beyond the MTU sizes. I will look at the SEAL > proposal and understand how its handled there.
Probably better to look at the latest AERO spec (posted today). I have it fixed there now. > For user-plane we are covered, the tunnel entry and exit point perform > fragmentation prior to the encapsulation and so generally this should not > cause any issues. We always have the ability to advertise a lower MTU > value on the access link; The MTU value that we advertise on the access > link should be the lower of the link MTU on the WLAN link and the Tunnel > MTU on the MAG-LMA path. This can be achieved by allowing the MAG to > include the adjusted MTU value in the DHCP OFFER and IPv6 Router > Advertisements. However, we realize not all mobile nodes honor the MTU > option in the DHCPOFFER; But, at least on the addressing plane we can > ensure we send the correct MTU values. I'm not much of a fan of advertised MTU values in RAs and such. It may be OK if your tunnel is point-to-point, but I want good MTU solution for NBMA tunnels where the MTU between neighbors A and B may be vastly different than the MTU between neighbors A and C. I also want there to be a guaranteed minimum and an unlimited maximum. With AERO, all paths are guaranteed to support a minimum MTU of 1500. But, larger packets can also go through (unfragmented) if the path MTU is sufficient. Thanks - Fred [email protected] > RFC 5844: (IPv4 Traffic from the Mobile Node) > " The DHCPOFFER message [RFC2131] sent to the mobile node MUST > include the Interface MTU option [RFC2132]. The DHCP servers in > the Proxy Mobile IPv6 domain MUST be configured to include the > Interface MTU option. The MTU value SHOULD reflect the tunnel MTU > for the bidirectional tunnel between the mobile access gateway and > the local mobility anchor." > > RFC 5213: (IPv6 Traffic from the Mobile Node) > > 3. The mobile access gateway SHOULD add the MTU option, as specified > in [RFC4861], to the Router Advertisement messages that it sends > on the access link. This will ensure the mobile node on the link > uses the advertised MTU value. The MTU value SHOULD reflect the > tunnel MTU for the bi-directional tunnel between the mobile > access gateway and the local mobility anchor. Considerations > from Section 6.9.5 SHOULD be applied for determining the tunnel > MTU value. > > > > Regards > Sri > > > On 9/23/14 8:50 AM, "Templin, Fred L" <[email protected]> wrote: > > >Sri, > > > >> I've seen some work on IPSecme WG on IKEv2 message fragmentation > >> for the same issue. > > > >I looked at this, and the approach is roughly the same as what I have > >been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for > >years. In other words, perform fragmentation and reassembly at a level > >above the encapsulating IP protocol headers and below the encapsulated > >IP protocol headers - a mid-layer fragmentation and reassembly. > > > >So, this brings up a few questions: > > > > 1) Does the concern apply only to large control messages, or also to > > large data packets? > > 2) How big can the control messages get - not only for just today but > > also going forward into the future? > > 3) Are we really so concerned about IP fragment dropping that we need > > to bump this up to a mid-layer frag/reass? > > > >Thanks - Fred > >[email protected] > > > >--- > > > >From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L > >Sent: Monday, September 22, 2014 4:45 PM > >To: Sri Gundavelli (sgundave); [email protected] > >Subject: Re: [DMM] Signaling Message Fragmentation > > > >Hi Sri, > > > >My understanding is that if a source sends fragmented messages it must > >have assurance > >that the destination has a large enough reassembly buffer. Since the > >minimum IPv6 > >reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented > >packets > >larger than 1500 bytes unless there is some other means of determining > >whether the > >destination's reassembly buffer can accommodate the larger size. > > > >How big do you need? > > > >Thanks - Fred > > > >From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli > >(sgundave) > >Sent: Thursday, September 18, 2014 1:04 PM > >To: [email protected] > >Subject: [DMM] Signaling Message Fragmentation > > > >[Discussion under the maintenance scope] > > > >With the standardization of all the new mobility options (ANI, QoS, IFOM, > >MNP..etc) and specially with the NAI/Domain type fields in some of > >those options, we are almost close to hitting the PBU/BU fragmentation > >limit. > > > >Any thoughts on how to deal with this ? How is it solved in other message > >based protocols ? I've seen some work on IPSecme WG on IKEv2 message > >fragmentation for the same issue. > > > >Should we do some thing here ? Or, if any one has invested time on this > >and has a proposal ? Comments ? > > > > > > > >Regards > >Sri _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
