Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Dario Tedeschi <dat@exegin.com> Fri, 09 November 2012 19:34 UTC
Return-Path: <dat@exegin.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6838A21F852C for <roll@ietfa.amsl.com>; Fri, 9 Nov 2012 11:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.317
X-Spam-Level:
X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfznLIuqXfOq for <roll@ietfa.amsl.com>; Fri, 9 Nov 2012 11:34:57 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5405121F8523 for <roll@ietf.org>; Fri, 9 Nov 2012 11:34:57 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so3237504pbb.31 for <roll@ietf.org>; Fri, 09 Nov 2012 11:34:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=3vvXYmgqaXdvFftz9yEC16hlaoFnWvbWOUt0kzHwJEk=; b=e3H9jW4TkJzAy4gJQQqWHXUm1xtdaJSqWFB8GFU1hI7t9oXPmrtASa1fGbseWhqCG2 aX09RAOzMHnZtQx4aqhdGTQUr8kytcqA6xva0xCN7W6qM0rPzTHPKodpncVVg2wd+QRx 23xPP1XeaBwbCPWGFA5+j7jOk44MzhBCy0XwAaBVYHU41ki+krKk9i9+lXIwQSk66GHr 0xQY1K3ojP+fgFXu56Rs7hKqr1twpkHPaSUCjpuYJUjNUV7gP62ZPOz8S+Eb/Gl8/P3T SBPFR9nyFBimGX+9HmJwxNCQuOMd6FrzmagWf0IN1XezvLxhg51eAmVO3cYdryuzFPUw ys+A==
Received: by 10.66.88.133 with SMTP id bg5mr34173864pab.80.1352489697152; Fri, 09 Nov 2012 11:34:57 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ni3sm18160478pbc.2.2012.11.09.11.34.55 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 11:34:56 -0800 (PST)
Message-ID: <509D5AF5.4040304@exegin.com>
Date: Fri, 09 Nov 2012 11:35:17 -0800
From: Dario Tedeschi <dat@exegin.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" <johui@cisco.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <B50D0F163D52B74DA572DD345D5044AF0F6EFA99@xmb-rcd-x04.cisco.com> <50932647.3050509@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F2837@xmb-rcd-x04.cisco.com> <5094202F.4010805@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F874A@xmb-rcd-x04.cisco.com> <509C03C2.50809@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F714CBF@xmb-rcd-x04.cisco.com> <509C5F00.2050204@exegin.com>
In-Reply-To: <509C5F00.2050204@exegin.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: ALoCoQn6BZUNuEOd0q1SbHC6Az2gZKPpxR2zX44XnOK1UIREtNa9qud8qrKSEoux4g4lhoJqjALq
Cc: "<roll@ietf.org>" <roll@ietf.org>
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2012 19:34:58 -0000
After some lengthy discussions, Owen Kirby and I think the use of a non-link-local mc address in the outer header is fine as long as that address *uniquely* identifies the MPL domain (whether it be IANA assigned or determined at run-time). - Dario On 08/11/2012 5:40 PM, Dario Tedeschi wrote: > On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote: >> Hi Dario, >> >> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi<dat@exegin.com> wrote: >> >>> On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote: >>>> With your approach (require link-local in the outer header), the >>>> IPv6 multicast address identifies the application endpoints *and* >>>> the MPL domain. For that reason, your approach really only needs a >>>> single identifier to both limit the flooding scope and determine >>>> the application endpoints. >>> It depends on what you mean by MPL domain. In my view, FF02::MPL >>> identifies the MPL domain, while the inner IPv6 destination address >>> identifies the application endpoint. >> Let me introduce a new term to help move the discussion forward: >> Dissemination Region - a connected set of MPL devices that attempt to >> forward the packet so that all devices receive the packet at least >> once. Another definition may be: a region within which the SeedID >> must be unique. > > OK, that makes sense to me. > >> >>>> I can see how that would work (as you demonstrated) if we make >>>> the restriction that the IPv6 multicast addresses used within an >>>> MPL domain have the same prefix that identifies the MPL domain >>>> itself. The trouble comes when you want to support the full >>>> generality that IPv6 multicast addresses used by application >>>> endpoints can be arbitrary. >>> The "generality", you talk of, is why protocols like MLD exist. MLD >>> informs routers of mc addresses other devices are interested in. >>> Essentially it provides routing information. How could we support >>> the "full generality" of mc addresses without this information >>> (whether implied or from something like MLD). With this in mind, I >>> don't understand the need for non-link-local scope in the outer >>> header, because the "generality" you seek would be determined by the >>> mc address of the original packet (i.e. the mc address of the inner >>> header). All my approach is really saying is that only the >>> original/inner mc address determines how far a packet will >>> propagate, regardless of routing domain. MPL could just be one of >>> many routing domains a mc packet must traverse before reaching its >>> furthermost boundary. Or MPL may be the only routing domain, where >>> the mc packet only reaches a sub-set of devices within the domain >>> (i.e. a multicast group or a set based on unicast-prefix-based mc). >> The original intent of MPL was to avoid any routing information >> within the Dissemination Region. A router then only maintains state >> about what multicast addresses are of interest to devices within the >> Dissemination Region. > > Yes I understand, but I'm not sure how we can avoid routing > information, if we are to support sending to sub-sets of devices > within one LLN (whether we use non-link-local or link-local in the > outer header). To me it sounds like we are trying to offer what a > storing network provides without actually storing any information on > the routers. For unicasts, in RPL, this done by offloading the burden > of storing routing information onto the RPL root node (i.e. > source-routing). This works for unicasts, but it wouldn't work for > multicasts. > > >> >>>> For example, how does MPL support an application that subscribes to >>>> a well-known non-link-local IPv6 multicast address? I guess one >>>> approach is to say that if the IPv6 multicast address is not a >>>> unicast-prefix-based multicast address, then it disseminates across >>>> the entire region of connected MPL forwarders. >>> Granted one could have a situation where all routers hear an mc >>> packet that is only intended for a subset of devices, but that does >>> not mean all routers need to forward that packet or pass it to a >>> higher layer. Again, this would depend on the inner mc address and >>> the routing information available to routers. The routers without >>> the appropriate routing information would not forward. Similarly, >>> routers without mc membership information from an app would not pass >>> the packet to the next higher layer. >> We have different thoughts on how a device determines whether or not >> to forward the packet. You take a routing perspective, where a >> device determines whether or not to forward based on the identifier >> for the application endpoints. In contrast, I view it as a device >> determines whether or not to forward based on the Dissemination >> Region it is in. Note that in my view, the Dissemination Region does >> not have to have any relationship with the identifier for application >> endpoints. In other words, you can configure the Dissemination >> Region without any knowledge of the multicast addresses that devices >> are interested in. > > OK I see your point of view more clearly now. I assume then that a > Dissemination Region would be defined by a non-link-local mc address > prefix, and if so, how would MPL routers become aware of it? Without > it how would a router be able to differentiate one Dissemination > Region from another? > > >> >>>> One minor point with your approach is that the delivery requires >>>> processing the MPL Option of the outer header and the inner IPv6 >>>> header. That isn't so nice from an architectural perspective, but >>>> that is what we did with RFC 6553. >>> Using non-link-local in the outer header does not mitigate that. The >>> forwarder still needs to look at the inner header to determine if >>> the inner mc address is one an app is listening on. In fact >>> implementing this is a bit messy compared to my approach, because >>> the forwarder has to look ahead into the packet before >>> decapsulating. My approach always requires decapsulation before >>> making any decision about where the packet must go next. It's >>> simpler and more consistent. I've actually had the >>> fortune/misfortune of implementing both and I can safely say the >>> link-local approach was cleaner. >> I'd argue that using non-link-local in the outer header helps to >> preserve the layering. >> 1) Processing the outer header allows a device to determine whether >> it is a part of the Dissemination Region and the packet was received >> before. >> 2) Processing the inner header allows a device to determine whether >> it should process the payload. >> >> Can you explain why a device needs to "look ahead" into the packet >> before decapsulating when using a non-link-local outer header? > > Lets say the packet has outer and inner destination addresses > [FF05::1234] and [FF05::5678], respectively. An app on a device > receiving this packet, might be interested in [FF05::1234] or > [FF05::5678] or both. Which version of the packet gets passed up: The > entire MPL encapsulated one or just the inner packet or both. To get > around this, I had to add a hack that would do two things: > 1. If the network device is a member of [FF05::1234] and there is no > IPv6-in-IPv6 encapsulation, then pass the packet up. > 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH > option and the network device is a member of [FF05::5678], then > decapsulate and pass the inner packet up. > > Note that logic 2. required looking ahead at the inner header to > determine if the mc address there was an address some higher layer was > interested in. What made things even less palatable, was having to > skip over potential extended headers just to determine whether or not > the packet was encapsulated. Aside from passing mc packets up, the > hack was also needed to decrement the hop-limit when forwarding. > > Back then, there was no idea of having an IANA assigned MPL mc-group > so I could not rely on a well-known non-link-local address. With a > well-known MPL address a MPL router would be able to be a member of > that group and always try decapsulate upon hearing a packet destined > for that address. Without this MPL mc address using the link-local > all-routers mc address, removed the need for the hack. This was > because all routers are members of the all-routers group. > > > >> >>>> In my approach (allow non-link-local in the outer header), I tried >>>> to separate out the identifiers for the application endpoints and >>>> the MPL domain. That is why I used the outer header's destination >>>> address to identify the MPL domain and the inner header's >>>> destination address to identify the application endpoints. With >>>> this approach, it actually becomes feasible to address situations >>>> where the devices within an MPL domain subscribe to arbitrary IPv6 >>>> multicast addresses - not just ones that are based on the unicast >>>> prefix. >>> Firstly, yes I agree the inner destination address should determine >>> the application endpoint. What I'm not clear on is why we need an >>> MPL domain to cover more than the LLN or why we need to support >>> multiple MPL domains in one LLN. Tf the latter case is required to >>> allow for different sets of MPL propagation parameters, then I'd >>> imagine that should rather be handled by the HbH option. >> Peter's use case involves having multiple Dissemination Regions >> within a single IEEE 802.15.4 PAN. I agree, one could argue whether >> the devices should all be within the same PAN or different PANs based >> on the nearest border router. > > Or an argument for having multiple Destination Regions identified by > some field in the HbH option. > > >> >> During the WG meeting, people made a good argument that we actually >> don't know the answer - either because all the use cases are not >> obvious or because we don't understand all the consequences of each >> approach. One proposal was to have the draft specify well-defined >> forwarding behavior that supports both situations. For example: >> 1) If the outer header has an IPv6 Destination Address matching the >> link-local all-MPL-forwarders address, do … >> 2) Otherwise, do … >> >> Then leave it up to those who are using this spec to determine what >> subset they want to use. Not sure if this is a reasonable approach >> and would like to get feedback from the WG. > > My current implementation is just such a hybrid, except that action 1 > is decided by scope and not the full address. From an implementation > point of view, I'd prefer not to have two code paths, but if it > satisfies everyone's needs and we have an IANA assigned address, I can > live with it. :-) > > - Dario > > > >
- [Roll] [roll] #105: trickle-mcast: how to determi… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Yoshihiro Ohba
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Jonathan Hui (johui)
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… peter van der Stok
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Don Sturek
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dario Tedeschi
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Dijk, Esko
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Michael Richardson
- Re: [Roll] [roll] #105: trickle-mcast: how to det… Robert Cragie
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker
- Re: [Roll] [roll] #105: trickle-mcast: how to det… roll issue tracker