Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

"Jonathan Hui (johui)" <johui@cisco.com> Sat, 03 November 2012 05:18 UTC

Return-Path: <johui@cisco.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 92ECB21F9B59 for <roll@ietfa.amsl.com>; Fri, 2 Nov 2012 22:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 n5agYxO2Dh4L for <roll@ietfa.amsl.com>; Fri, 2 Nov 2012 22:18:33 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0175F21F8558 for <roll@ietf.org>; Fri, 2 Nov 2012 22:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17018; q=dns/txt; s=iport; t=1351919913; x=1353129513; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jPEo4MpMOjVje8x7NwVP15pUZmYl42ZxvA9VyTb7+M4=; b=RjGjO2jkNaoRauiyF3UP+YJ7Xh7+6HFWsaos5juANi46LMI8sFwppcPj LQqw3UXx/Njb4nNRIMfoSGI+bFoZoDvwM0P9o4Hnnn3LKXnrMgwdZ3iD+ DB7ggtvsmS1SF1N0tGD1m0pXebGCaZRQn/TBkKdS4OBUAaxbl5H1B5ZOI A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAG+olFCtJXG+/2dsb2JhbAA6CsMwgQiCHwEBBBIBWQ0QAgEIDhQCGwcyFBECBA4FCBqHaJwOn3aMARAFhUZhA6RUgWuCb4FcHx4
X-IronPort-AV: E=Sophos; i="4.80,704,1344211200"; d="scan'208,217"; a="138387571"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 05:18:32 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA35IW2X020896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 05:18:32 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 00:18:31 -0500
From: "Jonathan Hui (johui)" <johui@cisco.com>
To: Dario Tedeschi <dat@exegin.com>
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNuEl+VKkUNGCnjEqLpghV1euTUw==
Date: Sat, 03 Nov 2012 05:18:30 +0000
Message-ID: <B50D0F163D52B74DA572DD345D5044AF0F6F874A@xmb-rcd-x04.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>
In-Reply-To: <5094202F.4010805@exegin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.146.175]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001
x-tm-as-result: No--44.486900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF0F6F874Axmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "<roll@ietf.org>" <roll@ietf.org>, "<draft-ietf-roll-trickle-mcast@tools.ietf.org>" <draft-ietf-roll-trickle-mcast@tools.ietf.org>, "<mcr@sandelman.ca>" <mcr@sandelman.ca>, "Jonathan Hui (johui)" <johui@cisco.com>
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: Sat, 03 Nov 2012 05:18:34 -0000

Hi Dario,

Thanks for the detailed example - I see our disconnect now.

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.  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.

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.

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.

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.

--
Jonathan Hui

On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <dat@exegin.com<mailto:dat@exegin.com>> wrote:

On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote:

On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <dat@exegin.com><mailto:dat@exegin.com> wrote:



I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder.


The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2).

Isn't that what multicast groups and/or unicast-prefix-based multicasts are for? That is to say, to reach a defined set of devices.






Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work.


As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to limit the region?

The destination in the inner header determines if the packet needs to be forwarded or not, or forwarded on a different interface.






As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression.


I agree.

Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?


Example: Two border routers (BR1 and BR2) each forming a network:

--- Network 1 (BR1) ---
Unicast prefix: FD01::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

--- Network 2 (BR2) ---
Unicast prefix: FD02::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96


  1.  A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1.
  2.  It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
  3.  The packet is received by a MPL router in network 2 (N2R1).
  4.  N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up.
  5.  N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded.
  6.  The packet is also received by a MPL router in network 1 (N1R1).
  7.  N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur.
  8.  N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64
  9.  N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
  10. N1R1 transmits the new resulting packet.
  11. The packet is received by another MPL router in network 1 (N1R2).
  12. Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel).
  13. N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur.
  14. N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64.
  15. N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
  16. N1R2 transmits the resulting packet.
  17. The packet is received by yet another MPL router in network 2 (N2R2).
  18. Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel).
  19. N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet.

Note:
I chose a non-MPL aware originator of a multicast packet, because I wanted to be more thorough. I could have chosen an example where the originator of the packet *was* a MPL aware device. In such a case, it would have encapsulated with its own MPL HbH option as if it were forwarding the packet (i.e. outer and inner destinations would have been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL aware devices sending non-link-local multicasts is the problem of fan-out: If such a device multicasts/broadcasts at the link-layer for IPv6 multicasts, then many MPL routers may hear the packet and try forward it with their own seeds. Although this wouldn't cause a real packet-storm, it would cause something close to it, depending on how many routers were in earshot of the originator. However, this is a general problem that has nothing to do with MPL's address scope.

Secondly, notice that FF02::MPL can be viewed as a well defined address for a "tunnel exit point". It just so happens that it actually identifies multiple physical "exit points".

- Dario