From nobody Thu Oct 1 12:03:40 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6666D1A8871 for ; Thu, 1 Oct 2015 12:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmEbcsGOGNba for ; Thu, 1 Oct 2015 12:03:35 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FB31A8874 for ; Thu, 1 Oct 2015 12:03:30 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so2889741wic.1 for ; Thu, 01 Oct 2015 12:03:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8db03LaY7n4842WU78WX7MQi7Y692qRsqxJ6HhuMalo=; b=J4SRbokBYbgvEUIP4vxA741hnf338Kxeqdx8ESdJW8BFm5AO6Pb/us7dbC84hxphVF jGWNIA2rCmRsFiHsfdmnbIT1tY5UncFwP8gvKn8aaUIFtMId6SS11m2FnxpE/yu6pL+Q VkVBtivttmj+A7PWYvA5/edZZ+aGrCZBMLro1oqoqgNgD17FgxckfyP5hseFaMCh0PTE 02fEsjqs9p2lqGShCm0CJ4zC9x8eVPvoECuWKH1TR9HZ4Q3LQ2RNjhu/6NDmgLj5y3qz bGqMgZdsaA/pzGZ78siTveOKVgrZmksfrVMBlD67DGDjrMuXXCCyYsym4phXSyvpdH88 ldYg== X-Gm-Message-State: ALoCoQlaaMrUJESwyz7HzRnmW5KL34P9VE8BL9Mx+R6ebvArKlyk/JkWrELQaefUpM8lRb8uW1Qvh7/hfbbguUIo+UysKleh5N5PpIh13He/biLVOfTx3aMoII+VlSC1htwN/yL/1M2pfmGnNEKyEvUHbg0H/AsJiyx9bi7h2MJ7NBfBfX71HFI= X-Received: by 10.194.90.20 with SMTP id bs20mr13691946wjb.87.1443726208962; Thu, 01 Oct 2015 12:03:28 -0700 (PDT) Received: from cskiralys-air.homenet.telecomitalia.it (host238-105-dynamic.31-79-r.retail.telecomitalia.it. [79.31.105.238]) by smtp.googlemail.com with ESMTPSA id x7sm4599787wia.5.2015.10.01.12.03.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 12:03:28 -0700 (PDT) To: Routing Over Low power and Lossy networks References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> From: Csaba Kiraly Message-ID: <560D8386.6000502@fbk.eu> Date: Thu, 1 Oct 2015 21:03:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 19:03:38 -0000 On 30/09/15 17:55, Joakim Eriksson wrote: >> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >> >> Hello Joakim, >> >> I have also worked on the Contiki DAO-ACK code, enabling ACKs, implementing fixes to the DAOSequence handling, and looking into multiple targets. > Nice, I have a PR on Contiki now with what we have been doing to get Contiki RPL more scalable (but still only single targets / paths). > >> What Cenk is saying sounds a reasonable hack, but the standard itself is in my opinion a bit underspecified for the semantics of DAO-ACK messages in several ways. > Yes, it is underspecified. There is need for clarifications and more details on the DAO / DAO ACK! > >> My preferred solution for ACKing DAO messages with multiple targets would be to have support for the same semantics that you would have had with one DAO message per Target, i.e., I would prefer an option field that gives an individual status for each Target. > Yes, but that would require more memory in the sending node to keep track of things or full specification of the target in the response. > I guess it might be solved by allowing multiple DAO ACKs for the same DAO and to have the Target options included in the DAO ACK. This is a compromise to consider for sure. If you look at my implementation, you can see that I use the routing table entry to match the DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not sure it would work in all cases, but it did work for the case I considered. I'm keeping only the SEQ, and I think this is a must if you have no aggregation, and you want to match in case you forward multiple DAOs before getting the ACK or timing out on it. In fact, simply enabling ACKs in the original code was messing up the match between DAOs and their ACKs because it wasn't even keeping track of the DAO sequence numbers. If you do aggregate ACKs, or you have more complex Target+Transit scenarios, the game changes, and I don't know what would be the balance between state you have to keep anyway and state you keep just to be able to interpret a later ACK correctly. I think it is implementation specific, so my suggestion would be a flag to indicate whether you request full ACK (bumping back all T+T info for rejected entries in the DAO) or a much smaller partial ACK with SEQ and similar IDs only. This flag (lets call it F for now), could go right next to K. As the DAO propagates, each node could set F based on whether it is able to store and/or reproduce info (F not set) or chose to remain stateless (set F ). This would exclude aggregation in the DAO-ACK sent down, but still allow for aggregation in the DAO sent up. > >> To give another example of subtle problems with DAO-ACK, it was not clear to me whether I want my implementation to ACK when the Target is added to the routing table, or only when this node itself receives an ACK for the same Target from its parent. Both makes sense, with the former giving a quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring that the path is actually built. Both look conformant to the standard, but I suppose the original author was thinking of the former, and I can easily see interoperability problems arising between two implementations using different semantics. >> > We did go for the end-to-end ACK to achieve better scalability. There is to me no point having a route to the parent if it is not possible to > get it all the way to root. But I totally agree - this is not obvious from the RPL RFC either. Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in the sense that it is still addressed to the next hop but you delay ACK till you know your parent (and all its parents) ACKed? > > Do you have your Contiki code somewhere in the open-source? I did some cleanup and pushed the clean part of the code to github: https://github.com/cskiraly/contiki/tree/DAO-NACK It is not yet rebased to the latest master, but it should apply. I suppose describing it would be too off-topic for the list. There is also the more experimental part of the code in a PR, if interested. Best regards, Csaba > > Best regards, > — Joakim > >> Best regards, >> Csaba >> >> On 29/09/15 23:08, Cenk Gündogan wrote: >>> Hello Joakim, >>> >>> This is an interesting question and I also couldn't find any answers in RFC 6550. >>> However, my thoughts on this are as follows: >>> Since a sub-set of the announced RPL targets could have been accepted before filling up >>> the routing table (e.g.), I would choose a status code between 1 and 127. >>> I would expect a node to choose another parent if a more aggressive status code is received ([128-255]). >>> But a full routing table can have free space again until the next or any subsequent DAO arrives .. >>> therefore I prefer a "mild rejection" with a status code of [1-127]. >>> >>> To give some feedback to the originator of the DAO, it might be sensible to copy the >>> rejected RPL Target options from the affected DAO to the DAO-ACK, so that the originator is fully >>> aware of which Target prefixes got rejected (and which ones got accepted, implicitly). >>> I would choose this method, because it doesn't require the originator of the DAO to save any extra state >>> about the DAO and its contents. >>> >>> Nonetheless, everything I wrote is nonconform and I am also interested in the RPL experts' opinions >>> and solutions. >>> >>> Best, >>> Cenk >>> >>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>> Hello All, >>>> >>>> I have spend quite some time to get a more stable implementation of DAO handling >>>> for Contiki RPL and I am currently looking into DAO aggregation. But I realised that >>>> it is for me not 100% clear what a node that receives a DAO with several prefixes to >>>> be registered but can only accept a sub-set of them. Should it be a DAO_NACK in >>>> this case or is there any other way to handle that case? >>>> >>>> If each would have been sent separately it is obvious that the receiving node can >>>> do a NACK when the routing table is full and therefore it is possible to get fine-grained >>>> answers. But with aggregation of DAOs this is not the case. >>>> >>>> Any ideas? >>>> >>>> Best regards, >>>> — Joakim Eriksson, SICS >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 1 13:03:22 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF21B2EEF for ; Thu, 1 Oct 2015 13:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzg_mE9STkmA for ; Thu, 1 Oct 2015 13:03:16 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B81B2EED for ; Thu, 1 Oct 2015 13:03:16 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so6379690wic.0 for ; Thu, 01 Oct 2015 13:03:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=TfCI/QKrpz9mhFuVa4h6Rj1mKj0xenj4crcUDGFd8lw=; b=eVhBzOgdICtlLNlJB5p/5grb6X7A823mO5G3eIquYIOaRj3ixCpLj7LDY4D3Vzyd6C FXcm+6oPO4wPSS8FKpcEGQLiatrr+0OU//VygFbwsvsiewNFH3ABwq6DAuf19+AyJvqF U80r45aHr4lvUK/2GDdaQgwwpCNBPDhQVbttUo3M11hIoTsuWzia8elq3Fp73guZrNqB OCX5sw31jbQReWN9R/WkQJv3oCtAHqbYTImRLMB1NHRiUAFM4try7YR/L2QZQeiVywzU jv09PBoUMmhSuoK7Go2sQ54Sb2lZB6pFhezx3Io1el7SVdFofT6ukT/vgq/Tj4Ob5Qgx g1nA== X-Gm-Message-State: ALoCoQmsZ2bFuKHum8iU+JFLa4xRjRihMOo3W34jfqt6l+BTbwVJwh91ObKzbO3+eptgB7Lls0yHdDRbOYx7oGYkZHKB0e5z/MB5Swxe1LAnXqjlWVvCwnsopJuxqJmoj7Oo09Hcd1MTukjsI/I4B1qtVpXCPIDeNOgKEyFgPGD+3T1XndF+BVg= X-Received: by 10.180.211.39 with SMTP id mz7mr548575wic.65.1443729794522; Thu, 01 Oct 2015 13:03:14 -0700 (PDT) Received: from cskiralys-air.homenet.telecomitalia.it (host238-105-dynamic.31-79-r.retail.telecomitalia.it. [79.31.105.238]) by smtp.googlemail.com with ESMTPSA id pu6sm7761920wjc.34.2015.10.01.13.03.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 13:03:13 -0700 (PDT) From: Csaba Kiraly To: Routing Over Low power and Lossy networks References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <8f1d44568afa4348a05169bedc3c3020@XCH-RCD-001.cisco.com> <518931B3-E437-4086-82B0-ADFB57F96646@sics.se> Message-ID: <560D9187.206@fbk.eu> Date: Thu, 1 Oct 2015 22:03:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <518931B3-E437-4086-82B0-ADFB57F96646@sics.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 20:03:19 -0000 On 30/09/15 18:06, Joakim Eriksson wrote: >> On 30 Sep 2015, at 09:58, Pascal Thubert (pthubert) wrote: >> >> Hello all: >> >> The DAO ACK status really is a summary that indicates that there was a problem or not, so if there is none, no need to dig further. With this, the only thing the child can do is globally pick another parent, and, depending on the range in the status, never come back. >> >> But the digging further, I agree, is not specified. If the groups wants it, we'll have to design additional stuff and draft it. >> > Yes - lets try to get this designed and detailed so that we can get interoperability between implementations! > I would be happy to provide what we have been doing to get our implementation working! > >> * We could use the status as an enumeration the way people probably expect it. But you'll note that we did not create a registry for it. > Not yet - I guess creating a registry might be fairly easy? > >> * Which hints you that we could also use it as a metric. A scalar degree of unwillingness to serve as a parent, that accounts for stuff like memory, available time slots in a chunk (for 6TiSCH) and/or battery depletion of the node. The status would translate in such things as serving as alternate but not as preferred parent. > Not sure that degree of unwillingness can be specified in a clear way so that everybody will interpret it the same way. But > sure - it is an option. I have done a “quick hack” and defined 255 as “Root is out of routes”. Because if you get that type of > response - there is no immediate need to look for another parent and another path - it will not work anyway… (that is if the > node is desired to get a path all the way to/from root). We did some tries with the memory aspect, and it is not bad, but not too good either. The information is simply not coming in at the right moment for a good decision logic. As Joakim said, squeezing it into one byte could also be too tight, and interoperability could be hindered. Would it be an absolute value with equations in the standard? If not, how would I confront the values received from two different implementations? How would I know that they are different and not comparable, in the first place? I think it is better to keep the status as an enumeration, but also keeping the high level semantics, like now, so that implementations that do not know the enum have some default behavior. BTW, 127 is specified both for partial and for outright reject in RFC6550. For the enum values, we differentiate 2 cases now, and we have different decision logic for them. I think it is a good idea to send the metrics you have described, but a DAO option or some DIO option is a better match. >> For more selective stuff, we would have to indicate the problem in the dao-ack per route advertisement that is a problem. This is a step that we did not take with RFC 6550, people advising that the draft was workable and thick enough without it. >> > Yes, and we were tired of writing more I guess - and eager to implement ;-) > >> The path that is really accepted in storing mode is self as a transit for a given target. Transit can be aggregated for multiple targets. And there can be multiple transits for a target. The DAO Ack could include the pairs (transit/target) that are trouble and indicate for each what the trouble is. It could in theory aggregate what's aggregatable, but the way the info in the dao ack is aggregated may have to differ from what was placed in the DAO. > Yes, the thing with todays RFC is that there is not yet any defined options for the DAO ACK - but that is of course easy to add. One other option > would be to add a flag into the DAO that says “all-or-nothing”. If it is set all routes or no-routes should be installed. It is a bit complex possibly but > it would be very clear when the DAO sending node gets the ack what happened. < 128 means all routes are installed. >=128 means none was > installed. I think all-or-nothing flag is a good idea, and relatively easy to implement. >> The path control delegates a right to propagate and eventually fan out the advertisement. If the T+T pair is placed in the dao ack, the path control could be used to refuse that right to propagate, so the child would be free to offer that particular pair to an alternate parent. We still have bits in the transit that could indicate stuff if we need it as well. > Yes, but I my case I am doing the simple case of just registering with one single parent / one single DAO path per target. > > > My current “plan” is to avoid aggregation when doing the regular DAO but possibly aggregate the no-path DAO since that one > can not possibly cause out-of-memory or other problems (or?). > This reminds me that the status code is not yet defined for No-path, right? It can be interpreted, but the text for 1-127 and 128-255 doesn't really apply. I'm not sure asking for an ACK on a no-path would makes sense, but the option is in the standard, and behavior is unspecified. Best regards, Csaba > Best regards, > — Joakim > >> Thoughts? >> >> Pascal >> >>> -----Original Message----- >>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk Gündogan >>> Sent: mardi 29 septembre 2015 23:08 >>> To: roll@ietf.org >>> Subject: Re: [Roll] Semantics of DAO ACK >>> >>> Hello Joakim, >>> >>> This is an interesting question and I also couldn't find any answers in RFC >>> 6550. >>> However, my thoughts on this are as follows: >>> Since a sub-set of the announced RPL targets could have been accepted >>> before filling up the routing table (e.g.), I would choose a status code >>> between 1 and 127. >>> I would expect a node to choose another parent if a more aggressive status >>> code is received ([128-255]). >>> But a full routing table can have free space again until the next or any >>> subsequent DAO arrives .. >>> therefore I prefer a "mild rejection" with a status code of [1-127]. >>> >>> To give some feedback to the originator of the DAO, it might be sensible to >>> copy the rejected RPL Target options from the affected DAO to the DAO- >>> ACK, so that the originator is fully aware of which Target prefixes got >>> rejected (and which ones got accepted, implicitly). >>> I would choose this method, because it doesn't require the originator of the >>> DAO to save any extra state about the DAO and its contents. >>> >>> Nonetheless, everything I wrote is nonconform and I am also interested in >>> the RPL experts' opinions and solutions. >>> >>> Best, >>> Cenk >>> >>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>> Hello All, >>>> >>>> I have spend quite some time to get a more stable implementation of >>>> DAO handling for Contiki RPL and I am currently looking into DAO >>>> aggregation. But I realised that it is for me not 100% clear what a >>>> node that receives a DAO with several prefixes to be registered but >>>> can only accept a sub-set of them. Should it be a DAO_NACK in this case >>> or is there any other way to handle that case? >>>> If each would have been sent separately it is obvious that the >>>> receiving node can do a NACK when the routing table is full and >>>> therefore it is possible to get fine-grained answers. But with aggregation >>> of DAOs this is not the case. >>>> Any ideas? >>>> >>>> Best regards, >>>> — Joakim Eriksson, SICS >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From nobody Thu Oct 1 13:11:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1B1A8992 for ; Thu, 1 Oct 2015 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKolQrYjeZ1Y for ; Thu, 1 Oct 2015 13:11:29 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79E61B2F18 for ; Thu, 1 Oct 2015 13:11:28 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so15802392lbc.3 for ; Thu, 01 Oct 2015 13:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Hqp5iY+iQR6QiP3BKheWJIdF/uj3iQYwm3nXGrUDCUg=; b=NuHulGvT+9BdllQb4H9iM8bS9goV5h0MRSpYt8IRkZpl6DQ3JgYzsAlxLobf1JYDi7 Gzz5PHR5OYUd/eNGOV7ckh84G5vU8dzuKmAeT5ACxwdoubhQQxgLK3ONMKGWxjGwuF+v iVtL93RdSuD5PypTytYXaPYXfWSfKMkKapPxkh1xfBYhhB4T/0tXnRFx+mvlU6scN8ue /O5wDw5QAC0YUkWOQc3RintK87sYQfEDeb/E+tNcgV48DkiCTb3KTJZt6WlOPl4R3wrr /YBPGdo7MuwBC2bPIa3arKY0/+tdbNd+HHgnULADpVQ17nS/Ojpdj/s0YYWV7OV/GxMq RIrA== X-Gm-Message-State: ALoCoQlkk3pJyVJhBM2qbM6fNS9z3jc8lrwQxzumhhNestHsOUjK9M9/v50QI6a1HLFqQoCVjI2E X-Received: by 10.25.155.75 with SMTP id d72mr2487355lfe.33.1443730286901; Thu, 01 Oct 2015 13:11:26 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id z204sm914103lfd.1.2015.10.01.13.11.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Oct 2015 13:11:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <560D8386.6000502@fbk.eu> Date: Thu, 1 Oct 2015 22:11:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 20:11:32 -0000 > On 01 Oct 2015, at 21:03, Csaba Kiraly wrote: >=20 >=20 >=20 > On 30/09/15 17:55, Joakim Eriksson wrote: >>> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >>>=20 >>> Hello Joakim, >>>=20 >>> I have also worked on the Contiki DAO-ACK code, enabling ACKs, = implementing fixes to the DAOSequence handling, and looking into = multiple targets. >> Nice, I have a PR on Contiki now with what we have been doing to get = Contiki RPL more scalable (but still only single targets / paths). >>=20 >>> What Cenk is saying sounds a reasonable hack, but the standard = itself is in my opinion a bit underspecified for the semantics of = DAO-ACK messages in several ways. >> Yes, it is underspecified. There is need for clarifications and more = details on the DAO / DAO ACK! >>=20 >>> My preferred solution for ACKing DAO messages with multiple targets = would be to have support for the same semantics that you would have had = with one DAO message per Target, i.e., I would prefer an option field = that gives an individual status for each Target. >> Yes, but that would require more memory in the sending node to keep = track of things or full specification of the target in the response. >> I guess it might be solved by allowing multiple DAO ACKs for the same = DAO and to have the Target options included in the DAO ACK. > This is a compromise to consider for sure. If you look at my = implementation, you can see that I use the routing table entry to match = the DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not = sure it would work in all cases, but it did work for the case I = considered. I'm keeping only the SEQ, and I think this is a must if you = have no aggregation, and you want to match in case you forward multiple = DAOs before getting the ACK or timing out on it. In fact, simply = enabling ACKs in the original code was messing up the match between DAOs = and their ACKs because it wasn't even keeping track of the DAO sequence = numbers. >=20 > If you do aggregate ACKs, or you have more complex Target+Transit = scenarios, the game changes, and I don't know what would be the balance = between state you have to keep anyway and state you keep just to be able = to interpret a later ACK correctly. I think it is implementation = specific, so my suggestion would be a flag to indicate whether you = request full ACK (bumping back all T+T info for rejected entries in the = DAO) or a much smaller partial ACK with SEQ and similar IDs only. This = flag (lets call it F for now), could go right next to K. As the DAO = propagates, each node could set F based on whether it is able to store = and/or reproduce info (F not set) or chose to remain stateless (set F ). = This would exclude aggregation in the DAO-ACK sent down, but still allow = for aggregation in the DAO sent up. >=20 >>=20 >>> To give another example of subtle problems with DAO-ACK, it was not = clear to me whether I want my implementation to ACK when the Target is = added to the routing table, or only when this node itself receives an = ACK for the same Target from its parent. Both makes sense, with the = former giving a quick one-hop ACK, while the latter works as an = end-to-end ACK, ensuring that the path is actually built. Both look = conformant to the standard, but I suppose the original author was = thinking of the former, and I can easily see interoperability problems = arising between two implementations using different semantics. >>>=20 >> We did go for the end-to-end ACK to achieve better scalability. There = is to me no point having a route to the parent if it is not possible to >> get it all the way to root. But I totally agree - this is not obvious = from the RPL RFC either. > Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in the = sense that it is still addressed to the next hop but you delay ACK till = you know your parent (and all its parents) ACKed? >=20 I mean end-to-end as in waiting for all the parents to ACK so that = before ACKing it is known that the route is properly installed where it needs to. >>=20 >> Do you have your Contiki code somewhere in the open-source? > I did some cleanup and pushed the clean part of the code to github: = https://github.com/cskiraly/contiki/tree/DAO-NACK > It is not yet rebased to the latest master, but it should apply. I = suppose describing it would be too off-topic for the list. > There is also the more experimental part of the code in a PR, if = interested. Ok - I=E2=80=99ll take a look! BTW: We have done a few deployments using our implementation using Yanzi = networks products - take a look at this video where 1000 nodes is deployed with Contiki RPL + our fixes and 20 = neighbors and routes per node. If without our fixes it would not work since Contiki RPL did not allow scaling beyond = number of neighbors and routes / node that well=20 before these fixes. http://www.yanzi.se/video.jsp?id=3D7 Best regards, =E2=80=94 Joakim Eriksson >=20 > Best regards, > Csaba >>=20 >> Best regards, >> =E2=80=94 Joakim >>=20 >>> Best regards, >>> Csaba >>>=20 >>> On 29/09/15 23:08, Cenk G=C3=BCndogan wrote: >>>> Hello Joakim, >>>>=20 >>>> This is an interesting question and I also couldn't find any = answers in RFC 6550. >>>> However, my thoughts on this are as follows: >>>> Since a sub-set of the announced RPL targets could have been = accepted before filling up >>>> the routing table (e.g.), I would choose a status code between 1 = and 127. >>>> I would expect a node to choose another parent if a more aggressive = status code is received ([128-255]). >>>> But a full routing table can have free space again until the next = or any subsequent DAO arrives .. >>>> therefore I prefer a "mild rejection" with a status code of = [1-127]. >>>>=20 >>>> To give some feedback to the originator of the DAO, it might be = sensible to copy the >>>> rejected RPL Target options from the affected DAO to the DAO-ACK, = so that the originator is fully >>>> aware of which Target prefixes got rejected (and which ones got = accepted, implicitly). >>>> I would choose this method, because it doesn't require the = originator of the DAO to save any extra state >>>> about the DAO and its contents. >>>>=20 >>>> Nonetheless, everything I wrote is nonconform and I am also = interested in the RPL experts' opinions >>>> and solutions. >>>>=20 >>>> Best, >>>> Cenk >>>>=20 >>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>> Hello All, >>>>>=20 >>>>> I have spend quite some time to get a more stable implementation = of DAO handling >>>>> for Contiki RPL and I am currently looking into DAO aggregation. = But I realised that >>>>> it is for me not 100% clear what a node that receives a DAO with = several prefixes to >>>>> be registered but can only accept a sub-set of them. Should it be = a DAO_NACK in >>>>> this case or is there any other way to handle that case? >>>>>=20 >>>>> If each would have been sent separately it is obvious that the = receiving node can >>>>> do a NACK when the routing table is full and therefore it is = possible to get fine-grained >>>>> answers. But with aggregation of DAOs this is not the case. >>>>>=20 >>>>> Any ideas? >>>>>=20 >>>>> Best regards, >>>>> =E2=80=94 Joakim Eriksson, SICS >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 1 13:27:12 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A071B2F1D for ; Thu, 1 Oct 2015 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzq_dAGN_LkK for ; Thu, 1 Oct 2015 13:27:05 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37D11B2F1F for ; Thu, 1 Oct 2015 13:27:04 -0700 (PDT) Received: by laer8 with SMTP id r8so81618483lae.2 for ; Thu, 01 Oct 2015 13:27:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wx8iHvZpDb0EqTnQ+mVP+z0c2E8w0YHElxLKJ0jd5f8=; b=kSuwhd6RZfUJ9k5sU+ULDdNc5mi+CCuWG0VLSMJeqK9CzgADd7BQFdojBPxzlAYPqQ M+2xrkp6bPtKCALN13yNUemaNyKoLqewSUhg9TRFGu76yI+eqlLjeZrRczwNdk1KhNSU A997FQCwmlDqJnO7eID/XyI2SLLKL0pLk3narahpg+YcSvRQsFQ1+oybzRhdwTt2p6xk xkK7LIpTabcItM/hFhHt4TYOO5AXx0uhpj2JQYf73J6BDc+T2n8UKw+Gl0jgrq1kXEAc tyVcilh0aJKDMB7G6hxT0j0PGO7Xnvru8fQdcZnAagAMty+9hifXuJkOo7lKkUrk2IDV rPWQ== X-Gm-Message-State: ALoCoQlqdl+Q2ueImuOAVZkZTwBsTZb/LVUU0HdH7Y1tamashxT/xfycOP0XmjfBqtuCXPNt8YSi X-Received: by 10.112.55.2 with SMTP id n2mr3987430lbp.59.1443731222876; Thu, 01 Oct 2015 13:27:02 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id r137sm920619lfe.34.2015.10.01.13.27.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Oct 2015 13:27:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <560D9187.206@fbk.eu> Date: Thu, 1 Oct 2015 22:27:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <8f1d44568afa4348a05169bedc3c3020@XCH-RCD-001.cisco.com> <518931B3-E437-4086-82B0-ADFB57F96646@sics.se> <560D9187.206@fbk.eu> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 20:27:07 -0000 > On 01 Oct 2015, at 22:03, Csaba Kiraly wrote: > On 30/09/15 18:06, Joakim Eriksson wrote: >>> On 30 Sep 2015, at 09:58, Pascal Thubert (pthubert) = wrote: >>> * Which hints you that we could also use it as a metric. A scalar = degree of unwillingness to serve as a parent, that accounts for stuff = like memory, available time slots in a chunk (for 6TiSCH) and/or battery = depletion of the node. The status would translate in such things as = serving as alternate but not as preferred parent. >> Not sure that degree of unwillingness can be specified in a clear way = so that everybody will interpret it the same way. But >> sure - it is an option. I have done a =E2=80=9Cquick hack=E2=80=9D = and defined 255 as =E2=80=9CRoot is out of routes=E2=80=9D. Because if = you get that type of >> response - there is no immediate need to look for another parent and = another path - it will not work anyway=E2=80=A6 (that is if the >> node is desired to get a path all the way to/from root). > We did some tries with the memory aspect, and it is not bad, but not = too good either. The information is simply not coming in at the right = moment for a good decision logic. As Joakim said, squeezing it into one = byte could also be too tight, and interoperability could be hindered. = Would it be an absolute value with equations in the standard? If not, = how would I confront the values received from two different = implementations? How would I know that they are different and not = comparable, in the first place? >=20 > I think it is better to keep the status as an enumeration, but also = keeping the high level semantics, like now, so that implementations that = do not know the enum have some default behavior. BTW, 127 is specified = both for partial and for outright reject in RFC6550. For the enum = values, we differentiate 2 cases now, and we have different decision = logic for them. >=20 > I think it is a good idea to send the metrics you have described, but = a DAO option or some DIO option is a better match. >=20 >>> For more selective stuff, we would have to indicate the problem in = the dao-ack per route advertisement that is a problem. This is a step = that we did not take with RFC 6550, people advising that the draft was = workable and thick enough without it. >>>=20 >> Yes, and we were tired of writing more I guess - and eager to = implement ;-) >>=20 >>> The path that is really accepted in storing mode is self as a = transit for a given target. Transit can be aggregated for multiple = targets. And there can be multiple transits for a target. The DAO Ack = could include the pairs (transit/target) that are trouble and indicate = for each what the trouble is. It could in theory aggregate what's = aggregatable, but the way the info in the dao ack is aggregated may have = to differ from what was placed in the DAO. >> Yes, the thing with todays RFC is that there is not yet any defined = options for the DAO ACK - but that is of course easy to add. One other = option >> would be to add a flag into the DAO that says =E2=80=9Call-or-nothing=E2= =80=9D. If it is set all routes or no-routes should be installed. It is = a bit complex possibly but >> it would be very clear when the DAO sending node gets the ack what = happened. < 128 means all routes are installed. >=3D128 means none was >> installed. > I think all-or-nothing flag is a good idea, and relatively easy to = implement. >=20 >>> The path control delegates a right to propagate and eventually fan = out the advertisement. If the T+T pair is placed in the dao ack, the = path control could be used to refuse that right to propagate, so the = child would be free to offer that particular pair to an alternate = parent. We still have bits in the transit that could indicate stuff if = we need it as well. >> Yes, but I my case I am doing the simple case of just registering = with one single parent / one single DAO path per target. >>=20 >>=20 >> My current =E2=80=9Cplan=E2=80=9D is to avoid aggregation when doing = the regular DAO but possibly aggregate the no-path DAO since that one >> can not possibly cause out-of-memory or other problems (or?). >>=20 > This reminds me that the status code is not yet defined for No-path, = right? It can be interpreted, but the text for 1-127 and 128-255 doesn't = really apply. I'm not sure asking for an ACK on a no-path would makes = sense, but the option is in the standard, and behavior is unspecified. I think we do request the ACK on no-path but do not retransmit. I guess = the only interpretation is =E2=80=9CYes the no-path was received=E2=80=9D = so I agree - only the unconditional accept seems like a valid answer. It = is also forwarded but no wait for the =E2=80=9Cend-to-end=E2=80=9D = no-path before sending the ACK. Retransmitting no-path might make sense if the packet got lost - just to ensure that = the route is fully removed and no =E2=80=9Cmemory leakage=E2=80=9D is = caused (but if feels that is not going to happen that often). Best regards, =E2=80=94 Joakim Eriksson > Best regards, > Csaba >=20 >> Best regards, >> =E2=80=94 Joakim >>=20 >>> Thoughts? >>>=20 >>> Pascal >>>=20 >>>> -----Original Message----- >>>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk = G=C3=BCndogan >>>> Sent: mardi 29 septembre 2015 23:08 >>>> To: roll@ietf.org >>>> Subject: Re: [Roll] Semantics of DAO ACK >>>>=20 >>>> Hello Joakim, >>>>=20 >>>> This is an interesting question and I also couldn't find any = answers in RFC >>>> 6550. >>>> However, my thoughts on this are as follows: >>>> Since a sub-set of the announced RPL targets could have been = accepted >>>> before filling up the routing table (e.g.), I would choose a status = code >>>> between 1 and 127. >>>> I would expect a node to choose another parent if a more aggressive = status >>>> code is received ([128-255]). >>>> But a full routing table can have free space again until the next = or any >>>> subsequent DAO arrives .. >>>> therefore I prefer a "mild rejection" with a status code of = [1-127]. >>>>=20 >>>> To give some feedback to the originator of the DAO, it might be = sensible to >>>> copy the rejected RPL Target options from the affected DAO to the = DAO- >>>> ACK, so that the originator is fully aware of which Target prefixes = got >>>> rejected (and which ones got accepted, implicitly). >>>> I would choose this method, because it doesn't require the = originator of the >>>> DAO to save any extra state about the DAO and its contents. >>>>=20 >>>> Nonetheless, everything I wrote is nonconform and I am also = interested in >>>> the RPL experts' opinions and solutions. >>>>=20 >>>> Best, >>>> Cenk >>>>=20 >>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>> Hello All, >>>>>=20 >>>>> I have spend quite some time to get a more stable implementation = of >>>>> DAO handling for Contiki RPL and I am currently looking into DAO >>>>> aggregation. But I realised that it is for me not 100% clear what = a >>>>> node that receives a DAO with several prefixes to be registered = but >>>>> can only accept a sub-set of them. Should it be a DAO_NACK in this = case >>>> or is there any other way to handle that case? >>>>> If each would have been sent separately it is obvious that the >>>>> receiving node can do a NACK when the routing table is full and >>>>> therefore it is possible to get fine-grained answers. But with = aggregation >>>> of DAOs this is not the case. >>>>> Any ideas? >>>>>=20 >>>>> Best regards, >>>>> =E2=80=94 Joakim Eriksson, SICS >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Oct 2 06:05:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFB31A1B43 for ; Fri, 2 Oct 2015 06:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBGNJSRoE6Fb for ; Fri, 2 Oct 2015 06:05:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD0B1A1B49 for ; Fri, 2 Oct 2015 06:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12338; q=dns/txt; s=iport; t=1443791122; x=1445000722; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nX3LfjrZ6mT4fS+dCradyF2MLbqZ8Q9y/yKtB+6E/h8=; b=YdsRwmIIFQxl95YFDqnI/CN0EkIgBMGlTis6yhwy0AI7FgAtHRa4mhon yIV3otz3YjUr49hg6RiGg/5WpvAQDLnFlpbEVcFSmX+ngy5JGjj08S5ip RsO97vdJFMiZxd9Yq2ax0GJrRpki9X1DHwYZxQVYpgnSG63a+CxC34fhq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgB+gA5W/4ENJK1egydUbga9eQENgXEKhXkCHIEeOBQBAQEBAQEBgQqEJAEBAQQBAQELFRExBgMXBAIBCBEEAQEBAgIjAwICAiULFAEICAIEEwgTiBMNtn2URAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIoVRg3iBBoQ0CjQiBoJjgUMFhz+Gd4dGAYUWh3mBXYdbjkODbgEfAQFCghEdgVRxAYguQ4EGAQEB X-IronPort-AV: E=Sophos;i="5.17,623,1437436800"; d="scan'208";a="34030169" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 02 Oct 2015 13:05:20 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t92D5KI8008159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Oct 2015 13:05:20 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Oct 2015 08:05:20 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Fri, 2 Oct 2015 08:05:20 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Semantics of DAO ACK Thread-Index: AQHQ/RLuUOW0iZzzpE24p86U+vUYyg== Date: Fri, 2 Oct 2015 13:04:54 +0000 Deferred-Delivery: Fri, 2 Oct 2015 13:04:36 +0000 Message-ID: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 13:05:32 -0000 SGVsbG8gSm9ha2ltOg0KDQpXaGF0IEkgcmVhZCBoZXJlIGJvaWxzIGRvd24gdG8gYSBsaW1pdGVk IGRpZmZ1c2lvbiBhbGdvcml0aG0uIFdlIHRyaWVkIHRvIGF2b2lkIHRoYXQgaW4gUlBMIGJlY2F1 c2UgYW55IG1vdmVtZW50IHdpdGhpbiB0aGUgY29udmVyZ2VuY2Ugd291bGQgY2F1c2UgYSBkZWFk bG9jay4gSU9XIGlmIGV2ZXJ5IG5vZGUgd2FpdHMgZm9yIChhbGwgb2YpIHRoZSBwYXJlbnRzIHRv IGFjaywgdGhlbiB0aGlzIHJlY3Vyc2l2ZWx5IHRha2VzIHlvdSB0byB0aGUgcm9vdCwgYW5kIGlm IGFueSBub2RlIGluIHRoZSBjaGFpbiBtb3ZlcyBvciBkaWVzLCB0aGUgZGlmZnVzaW9uIHdpbGwg bm90IGJlIGNvbXBsZXRlLiANCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9ha2ltIEVyaWtzc29uDQo+IFNlbnQ6IGpldWRpIDEgb2N0b2JyZSAy MDE1IDIyOjExDQo+IFRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jr cyA8cm9sbEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtSb2xsXSBTZW1hbnRpY3Mgb2YgREFP IEFDSw0KPiANCj4gDQo+ID4gT24gMDEgT2N0IDIwMTUsIGF0IDIxOjAzLCBDc2FiYSBLaXJhbHkg PGtpcmFseUBmYmsuZXU+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIDMwLzA5LzE1IDE3 OjU1LCBKb2FraW0gRXJpa3Nzb24gd3JvdGU6DQo+ID4+PiBPbiAzMCBTZXAgMjAxNSwgYXQgMDY6 NDQsIENzYWJhIEtpcmFseSA8a2lyYWx5QGZiay5ldT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGVs bG8gSm9ha2ltLA0KPiA+Pj4NCj4gPj4+IEkgaGF2ZSBhbHNvIHdvcmtlZCBvbiB0aGUgQ29udGlr aSBEQU8tQUNLIGNvZGUsIGVuYWJsaW5nIEFDS3MsDQo+IGltcGxlbWVudGluZyBmaXhlcyB0byB0 aGUgREFPU2VxdWVuY2UgaGFuZGxpbmcsIGFuZCBsb29raW5nIGludG8gbXVsdGlwbGUNCj4gdGFy Z2V0cy4NCj4gPj4gTmljZSwgSSBoYXZlIGEgUFIgb24gQ29udGlraSBub3cgd2l0aCB3aGF0IHdl IGhhdmUgYmVlbiBkb2luZyB0byBnZXQNCj4gQ29udGlraSBSUEwgbW9yZSBzY2FsYWJsZSAoYnV0 IHN0aWxsIG9ubHkgc2luZ2xlIHRhcmdldHMgLyBwYXRocykuDQo+ID4+DQo+ID4+PiBXaGF0IENl bmsgaXMgc2F5aW5nIHNvdW5kcyBhIHJlYXNvbmFibGUgaGFjaywgYnV0IHRoZSBzdGFuZGFyZCBp dHNlbGYNCj4gaXMgaW4gbXkgb3BpbmlvbiBhIGJpdCB1bmRlcnNwZWNpZmllZCBmb3IgdGhlIHNl bWFudGljcyBvZiBEQU8tQUNLDQo+IG1lc3NhZ2VzIGluIHNldmVyYWwgd2F5cy4NCj4gPj4gWWVz LCBpdCBpcyB1bmRlcnNwZWNpZmllZC4gVGhlcmUgaXMgbmVlZCBmb3IgY2xhcmlmaWNhdGlvbnMg YW5kIG1vcmUgZGV0YWlscw0KPiBvbiB0aGUgREFPIC8gREFPIEFDSyENCj4gPj4NCj4gPj4+IE15 IHByZWZlcnJlZCBzb2x1dGlvbiBmb3IgQUNLaW5nIERBTyBtZXNzYWdlcyB3aXRoIG11bHRpcGxl IHRhcmdldHMNCj4gd291bGQgYmUgdG8gaGF2ZSBzdXBwb3J0IGZvciB0aGUgc2FtZSBzZW1hbnRp Y3MgdGhhdCB5b3Ugd291bGQgaGF2ZSBoYWQNCj4gd2l0aCBvbmUgREFPIG1lc3NhZ2UgcGVyIFRh cmdldCwgaS5lLiwgSSB3b3VsZCBwcmVmZXIgYW4gb3B0aW9uIGZpZWxkIHRoYXQNCj4gZ2l2ZXMg YW4gaW5kaXZpZHVhbCBzdGF0dXMgZm9yIGVhY2ggVGFyZ2V0Lg0KPiA+PiBZZXMsIGJ1dCB0aGF0 IHdvdWxkIHJlcXVpcmUgbW9yZSBtZW1vcnkgaW4gdGhlIHNlbmRpbmcgbm9kZSB0byBrZWVwDQo+ IHRyYWNrIG9mIHRoaW5ncyBvciBmdWxsIHNwZWNpZmljYXRpb24gb2YgdGhlIHRhcmdldCBpbiB0 aGUgcmVzcG9uc2UuDQo+ID4+IEkgZ3Vlc3MgaXQgbWlnaHQgYmUgc29sdmVkIGJ5IGFsbG93aW5n IG11bHRpcGxlIERBTyBBQ0tzIGZvciB0aGUgc2FtZQ0KPiBEQU8gYW5kIHRvIGhhdmUgdGhlIFRh cmdldCBvcHRpb25zIGluY2x1ZGVkIGluIHRoZSBEQU8gQUNLLg0KPiA+IFRoaXMgaXMgYSBjb21w cm9taXNlIHRvIGNvbnNpZGVyIGZvciBzdXJlLiBJZiB5b3UgbG9vayBhdCBteQ0KPiBpbXBsZW1l bnRhdGlvbiwgeW91IGNhbiBzZWUgdGhhdCBJIHVzZSB0aGUgcm91dGluZyB0YWJsZSBlbnRyeSB0 byBtYXRjaCB0aGUNCj4gREFPIEFDSywgYW5kIEkga2VlcCBvbmx5IERBT1NlcXVlbmNlIChTRVEp IGFzIGV4dHJhIHN0YXRlLiBJJ20gbm90IHN1cmUgaXQNCj4gd291bGQgd29yayBpbiBhbGwgY2Fz ZXMsIGJ1dCBpdCBkaWQgd29yayBmb3IgdGhlIGNhc2UgSSBjb25zaWRlcmVkLiBJJ20NCj4ga2Vl cGluZyBvbmx5IHRoZSBTRVEsIGFuZCBJIHRoaW5rIHRoaXMgaXMgYSBtdXN0IGlmIHlvdSBoYXZl IG5vIGFnZ3JlZ2F0aW9uLA0KPiBhbmQgeW91IHdhbnQgdG8gbWF0Y2ggaW4gY2FzZSB5b3UgZm9y d2FyZCBtdWx0aXBsZSBEQU9zIGJlZm9yZSBnZXR0aW5nDQo+IHRoZSBBQ0sgb3IgdGltaW5nIG91 dCBvbiBpdC4gSW4gZmFjdCwgc2ltcGx5IGVuYWJsaW5nIEFDS3MgaW4gdGhlIG9yaWdpbmFsDQo+ IGNvZGUgd2FzIG1lc3NpbmcgdXAgdGhlIG1hdGNoIGJldHdlZW4gREFPcyBhbmQgdGhlaXIgQUNL cyBiZWNhdXNlIGl0DQo+IHdhc24ndCBldmVuIGtlZXBpbmcgdHJhY2sgb2YgdGhlIERBTyBzZXF1 ZW5jZSBudW1iZXJzLg0KPiA+DQo+ID4gSWYgeW91IGRvIGFnZ3JlZ2F0ZSBBQ0tzLCBvciB5b3Ug aGF2ZSBtb3JlIGNvbXBsZXggVGFyZ2V0K1RyYW5zaXQNCj4gc2NlbmFyaW9zLCB0aGUgZ2FtZSBj aGFuZ2VzLCBhbmQgSSBkb24ndCBrbm93IHdoYXQgd291bGQgYmUgdGhlIGJhbGFuY2UNCj4gYmV0 d2VlbiBzdGF0ZSB5b3UgaGF2ZSB0byBrZWVwIGFueXdheSBhbmQgc3RhdGUgeW91IGtlZXAganVz dCB0byBiZSBhYmxlDQo+IHRvIGludGVycHJldCBhIGxhdGVyIEFDSyBjb3JyZWN0bHkuIEkgdGhp bmsgaXQgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIHNvIG15DQo+IHN1Z2dlc3Rpb24gd291 bGQgYmUgYSBmbGFnIHRvIGluZGljYXRlIHdoZXRoZXIgeW91IHJlcXVlc3QgZnVsbCBBQ0sNCj4g KGJ1bXBpbmcgYmFjayBhbGwgVCtUIGluZm8gZm9yIHJlamVjdGVkIGVudHJpZXMgaW4gdGhlIERB Tykgb3IgYSBtdWNoDQo+IHNtYWxsZXIgcGFydGlhbCBBQ0sgd2l0aCBTRVEgYW5kIHNpbWlsYXIg SURzIG9ubHkuIFRoaXMgZmxhZyAobGV0cyBjYWxsIGl0IEYgZm9yDQo+IG5vdyksIGNvdWxkIGdv IHJpZ2h0IG5leHQgdG8gSy4gQXMgdGhlIERBTyBwcm9wYWdhdGVzLCBlYWNoIG5vZGUgY291bGQg c2V0DQo+IEYgYmFzZWQgb24gd2hldGhlciBpdCBpcyBhYmxlIHRvIHN0b3JlIGFuZC9vciByZXBy b2R1Y2UgaW5mbyAoRiBub3Qgc2V0KSBvcg0KPiBjaG9zZSB0byByZW1haW4gc3RhdGVsZXNzIChz ZXQgRiApLiBUaGlzIHdvdWxkIGV4Y2x1ZGUgYWdncmVnYXRpb24gaW4gdGhlDQo+IERBTy1BQ0sg c2VudCBkb3duLCBidXQgc3RpbGwgYWxsb3cgZm9yIGFnZ3JlZ2F0aW9uIGluIHRoZSBEQU8gc2Vu dCB1cC4NCj4gPg0KPiA+Pg0KPiA+Pj4gVG8gZ2l2ZSBhbm90aGVyIGV4YW1wbGUgb2Ygc3VidGxl IHByb2JsZW1zIHdpdGggREFPLUFDSywgaXQgd2FzIG5vdA0KPiBjbGVhciB0byBtZSB3aGV0aGVy IEkgd2FudCBteSBpbXBsZW1lbnRhdGlvbiB0byBBQ0sgd2hlbiB0aGUgVGFyZ2V0IGlzDQo+IGFk ZGVkIHRvIHRoZSByb3V0aW5nIHRhYmxlLCBvciBvbmx5IHdoZW4gdGhpcyBub2RlIGl0c2VsZiBy ZWNlaXZlcyBhbiBBQ0sgZm9yDQo+IHRoZSBzYW1lIFRhcmdldCBmcm9tIGl0cyBwYXJlbnQuIEJv dGggbWFrZXMgc2Vuc2UsIHdpdGggdGhlIGZvcm1lciBnaXZpbmcgYQ0KPiBxdWljayBvbmUtaG9w IEFDSywgd2hpbGUgdGhlIGxhdHRlciB3b3JrcyBhcyBhbiBlbmQtdG8tZW5kIEFDSywgZW5zdXJp bmcNCj4gdGhhdCB0aGUgcGF0aCBpcyBhY3R1YWxseSBidWlsdC4gQm90aCBsb29rIGNvbmZvcm1h bnQgdG8gdGhlIHN0YW5kYXJkLCBidXQgSQ0KPiBzdXBwb3NlIHRoZSBvcmlnaW5hbCBhdXRob3Ig d2FzIHRoaW5raW5nIG9mIHRoZSBmb3JtZXIsIGFuZCBJIGNhbiBlYXNpbHkgc2VlDQo+IGludGVy b3BlcmFiaWxpdHkgcHJvYmxlbXMgYXJpc2luZyBiZXR3ZWVuIHR3byBpbXBsZW1lbnRhdGlvbnMg dXNpbmcNCj4gZGlmZmVyZW50IHNlbWFudGljcy4NCj4gPj4+DQo+ID4+IFdlIGRpZCBnbyBmb3Ig dGhlIGVuZC10by1lbmQgQUNLIHRvIGFjaGlldmUgYmV0dGVyIHNjYWxhYmlsaXR5LiBUaGVyZQ0K PiA+PiBpcyB0byBtZSBubyBwb2ludCBoYXZpbmcgYSByb3V0ZSB0byB0aGUgcGFyZW50IGlmIGl0 IGlzIG5vdCBwb3NzaWJsZSB0byBnZXQNCj4gaXQgYWxsIHRoZSB3YXkgdG8gcm9vdC4gQnV0IEkg dG90YWxseSBhZ3JlZSAtIHRoaXMgaXMgbm90IG9idmlvdXMgZnJvbSB0aGUgUlBMDQo+IFJGQyBl aXRoZXIuDQo+ID4gRG8geW91IG1lYW4gZW5kLXRvLWVuZCBBQ0sgYXMgaW4gbm9uLXN0b3Jpbmcs IG9yIGVuZC10by1lbmQgQUNLIGluIHRoZQ0KPiBzZW5zZSB0aGF0IGl0IGlzIHN0aWxsIGFkZHJl c3NlZCB0byB0aGUgbmV4dCBob3AgYnV0IHlvdSBkZWxheSBBQ0sgdGlsbCB5b3UNCj4ga25vdyB5 b3VyIHBhcmVudCAoYW5kIGFsbCBpdHMgcGFyZW50cykgQUNLZWQ/DQo+ID4NCj4gDQo+IEkgbWVh biBlbmQtdG8tZW5kIGFzIGluIHdhaXRpbmcgZm9yIGFsbCB0aGUgcGFyZW50cyB0byBBQ0sgc28g dGhhdCBiZWZvcmUNCj4gQUNLaW5nIGl0IGlzIGtub3duIHRoYXQgdGhlIHJvdXRlIGlzIHByb3Bl cmx5IGluc3RhbGxlZCB3aGVyZSBpdCBuZWVkcyB0by4NCj4gDQo+ID4+DQo+ID4+IERvIHlvdSBo YXZlIHlvdXIgQ29udGlraSBjb2RlIHNvbWV3aGVyZSBpbiB0aGUgb3Blbi1zb3VyY2U/DQo+ID4g SSBkaWQgc29tZSBjbGVhbnVwIGFuZCBwdXNoZWQgdGhlIGNsZWFuIHBhcnQgb2YgdGhlIGNvZGUg dG8gZ2l0aHViOg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9jc2tpcmFseS9jb250aWtpL3RyZWUv REFPLU5BQ0sNCj4gPiBJdCBpcyBub3QgeWV0IHJlYmFzZWQgdG8gdGhlIGxhdGVzdCBtYXN0ZXIs IGJ1dCBpdCBzaG91bGQgYXBwbHkuIEkgc3VwcG9zZQ0KPiBkZXNjcmliaW5nIGl0IHdvdWxkIGJl IHRvbyBvZmYtdG9waWMgZm9yIHRoZSBsaXN0Lg0KPiA+IFRoZXJlIGlzIGFsc28gdGhlIG1vcmUg ZXhwZXJpbWVudGFsIHBhcnQgb2YgdGhlIGNvZGUgaW4gYSBQUiwgaWYgaW50ZXJlc3RlZC4NCj4g DQo+IE9rIC0gSeKAmWxsIHRha2UgYSBsb29rIQ0KPiANCj4gQlRXOiBXZSBoYXZlIGRvbmUgYSBm ZXcgZGVwbG95bWVudHMgdXNpbmcgb3VyIGltcGxlbWVudGF0aW9uIHVzaW5nDQo+IFlhbnppIG5l dHdvcmtzIHByb2R1Y3RzIC0gdGFrZSBhIGxvb2sgYXQgdGhpcyB2aWRlbyB3aGVyZSAxMDAwIG5v ZGVzIGlzDQo+IGRlcGxveWVkIHdpdGggQ29udGlraSBSUEwgKyBvdXIgZml4ZXMgYW5kIDIwIG5l aWdoYm9ycyBhbmQgcm91dGVzIHBlcg0KPiBub2RlLiBJZiB3aXRob3V0IG91ciBmaXhlcyBpdCB3 b3VsZCBub3Qgd29yayBzaW5jZSBDb250aWtpIFJQTCBkaWQgbm90IGFsbG93DQo+IHNjYWxpbmcg YmV5b25kIG51bWJlciBvZiBuZWlnaGJvcnMgYW5kIHJvdXRlcyAvIG5vZGUgdGhhdCB3ZWxsIGJl Zm9yZQ0KPiB0aGVzZSBmaXhlcy4NCj4gDQo+IGh0dHA6Ly93d3cueWFuemkuc2UvdmlkZW8uanNw P2lkPTcNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4g4oCUIEpvYWtpbSBFcmlrc3Nvbg0KPiANCj4g Pg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBDc2FiYQ0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMs DQo+ID4+IOKAlCBKb2FraW0NCj4gPj4NCj4gPj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+IENzYWJh DQo+ID4+Pg0KPiA+Pj4gT24gMjkvMDkvMTUgMjM6MDgsIENlbmsgR8O8bmRvZ2FuIHdyb3RlOg0K PiA+Pj4+IEhlbGxvIEpvYWtpbSwNCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgaXMgYW4gaW50ZXJlc3Rp bmcgcXVlc3Rpb24gYW5kIEkgYWxzbyBjb3VsZG4ndCBmaW5kIGFueSBhbnN3ZXJzIGluDQo+IFJG QyA2NTUwLg0KPiA+Pj4+IEhvd2V2ZXIsIG15IHRob3VnaHRzIG9uIHRoaXMgYXJlIGFzIGZvbGxv d3M6DQo+ID4+Pj4gU2luY2UgYSBzdWItc2V0IG9mIHRoZSBhbm5vdW5jZWQgUlBMIHRhcmdldHMg Y291bGQgaGF2ZSBiZWVuDQo+ID4+Pj4gYWNjZXB0ZWQgYmVmb3JlIGZpbGxpbmcgdXAgdGhlIHJv dXRpbmcgdGFibGUgKGUuZy4pLCBJIHdvdWxkIGNob29zZSBhDQo+IHN0YXR1cyBjb2RlIGJldHdl ZW4gMSBhbmQgMTI3Lg0KPiA+Pj4+IEkgd291bGQgZXhwZWN0IGEgbm9kZSB0byBjaG9vc2UgYW5v dGhlciBwYXJlbnQgaWYgYSBtb3JlIGFnZ3Jlc3NpdmUNCj4gc3RhdHVzIGNvZGUgaXMgcmVjZWl2 ZWQgKFsxMjgtMjU1XSkuDQo+ID4+Pj4gQnV0IGEgZnVsbCByb3V0aW5nIHRhYmxlIGNhbiBoYXZl IGZyZWUgc3BhY2UgYWdhaW4gdW50aWwgdGhlIG5leHQgb3IgYW55DQo+IHN1YnNlcXVlbnQgREFP IGFycml2ZXMgLi4NCj4gPj4+PiB0aGVyZWZvcmUgSSBwcmVmZXIgYSAibWlsZCByZWplY3Rpb24i IHdpdGggYSBzdGF0dXMgY29kZSBvZiBbMS0xMjddLg0KPiA+Pj4+DQo+ID4+Pj4gVG8gZ2l2ZSBz b21lIGZlZWRiYWNrIHRvIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBEQU8sIGl0IG1pZ2h0IGJlDQo+ ID4+Pj4gc2Vuc2libGUgdG8gY29weSB0aGUgcmVqZWN0ZWQgUlBMIFRhcmdldCBvcHRpb25zIGZy b20gdGhlIGFmZmVjdGVkDQo+ID4+Pj4gREFPIHRvIHRoZSBEQU8tQUNLLCBzbyB0aGF0IHRoZSBv cmlnaW5hdG9yIGlzIGZ1bGx5IGF3YXJlIG9mIHdoaWNoDQo+IFRhcmdldCBwcmVmaXhlcyBnb3Qg cmVqZWN0ZWQgKGFuZCB3aGljaCBvbmVzIGdvdCBhY2NlcHRlZCwgaW1wbGljaXRseSkuDQo+ID4+ Pj4gSSB3b3VsZCBjaG9vc2UgdGhpcyBtZXRob2QsIGJlY2F1c2UgaXQgZG9lc24ndCByZXF1aXJl IHRoZQ0KPiA+Pj4+IG9yaWdpbmF0b3Igb2YgdGhlIERBTyB0byBzYXZlIGFueSBleHRyYSBzdGF0 ZSBhYm91dCB0aGUgREFPIGFuZCBpdHMNCj4gY29udGVudHMuDQo+ID4+Pj4NCj4gPj4+PiBOb25l dGhlbGVzcywgZXZlcnl0aGluZyBJIHdyb3RlIGlzIG5vbmNvbmZvcm0gYW5kIEkgYW0gYWxzbw0K PiA+Pj4+IGludGVyZXN0ZWQgaW4gdGhlIFJQTCBleHBlcnRzJyBvcGluaW9ucyBhbmQgc29sdXRp b25zLg0KPiA+Pj4+DQo+ID4+Pj4gQmVzdCwNCj4gPj4+PiBDZW5rDQo+ID4+Pj4NCj4gPj4+PiBP biAyOS4wOS4yMDE1IDIxOjQ0LCBKb2FraW0gRXJpa3Nzb24gd3JvdGU6DQo+ID4+Pj4+IEhlbGxv IEFsbCwNCj4gPj4+Pj4NCj4gPj4+Pj4gSSBoYXZlIHNwZW5kIHF1aXRlIHNvbWUgdGltZSB0byBn ZXQgYSBtb3JlIHN0YWJsZSBpbXBsZW1lbnRhdGlvbg0KPiA+Pj4+PiBvZiBEQU8gaGFuZGxpbmcg Zm9yIENvbnRpa2kgUlBMIGFuZCBJIGFtIGN1cnJlbnRseSBsb29raW5nIGludG8NCj4gPj4+Pj4g REFPIGFnZ3JlZ2F0aW9uLiBCdXQgSSByZWFsaXNlZCB0aGF0IGl0IGlzIGZvciBtZSBub3QgMTAw JSBjbGVhcg0KPiA+Pj4+PiB3aGF0IGEgbm9kZSB0aGF0IHJlY2VpdmVzIGEgREFPIHdpdGggc2V2 ZXJhbCBwcmVmaXhlcyB0byBiZQ0KPiA+Pj4+PiByZWdpc3RlcmVkIGJ1dCBjYW4gb25seSBhY2Nl cHQgYSBzdWItc2V0IG9mIHRoZW0uIFNob3VsZCBpdCBiZSBhDQo+IERBT19OQUNLIGluIHRoaXMg Y2FzZSBvciBpcyB0aGVyZSBhbnkgb3RoZXIgd2F5IHRvIGhhbmRsZSB0aGF0IGNhc2U/DQo+ID4+ Pj4+DQo+ID4+Pj4+IElmIGVhY2ggd291bGQgaGF2ZSBiZWVuIHNlbnQgc2VwYXJhdGVseSBpdCBp cyBvYnZpb3VzIHRoYXQgdGhlDQo+ID4+Pj4+IHJlY2VpdmluZyBub2RlIGNhbiBkbyBhIE5BQ0sg d2hlbiB0aGUgcm91dGluZyB0YWJsZSBpcyBmdWxsIGFuZA0KPiA+Pj4+PiB0aGVyZWZvcmUgaXQg aXMgcG9zc2libGUgdG8gZ2V0IGZpbmUtZ3JhaW5lZCBhbnN3ZXJzLiBCdXQgd2l0aA0KPiBhZ2dy ZWdhdGlvbiBvZiBEQU9zIHRoaXMgaXMgbm90IHRoZSBjYXNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBB bnkgaWRlYXM/DQo+ID4+Pj4+DQo+ID4+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+Pj4g4oCUIEpv YWtpbSBFcmlrc3NvbiwgU0lDUw0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBS b2xsQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbA0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gPj4+PiBSb2xsQGlldGYub3JnDQo+ ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+ID4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gUm9s bCBtYWlsaW5nIGxpc3QNCj4gPj4+IFJvbGxAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+PiBS b2xsQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+IFJvbGxAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0 DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsDQo= From nobody Fri Oct 2 08:18:59 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C4E1A7007 for ; Fri, 2 Oct 2015 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAugp2UFaDOh for ; Fri, 2 Oct 2015 08:18:54 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799EB1A6FE7 for ; Fri, 2 Oct 2015 08:18:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so38395622wic.1 for ; Fri, 02 Oct 2015 08:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=/CmL+52MRsMMcVSmMlaQ6tMZ3S6yH734NRiF/9AHHWo=; b=eDKfONhYb9TXR9piRzPpf+Z4CBsu76qDW4O1vIfKKRsLGCFuwzXloz9zwm/ozZODL2 6+jQt/OLgCP5D/W7pjtzP5gQUKy85swmrNWk1RWmmZsoiC7obRfO2ratlN6JcO2Joih5 hUrcZn7Z2/UmEKH/8Zl3HwWyD8slJMUJUYmrv0qAz+b93sYvFeAaNLvcEtvbDTZBeJIi EkqsmMQ0UYiOPX/P7xpNASc3H+iJ59ZRK04TusdsTpmxd9N5FH96sni7tPbQEcsUiq5S P0YmUyqnLP3CZrh2E1szVCfWgegUL8KT1fBNGNiLxjoJsqPsyq3+TR33KTtWWlXwVQcN q9KA== X-Gm-Message-State: ALoCoQnRd9U3PP80d3nNRg58KL+Hu+Wp9mMye1L9VU9pdPOqSVXlWedBWh6g69LYaNZLbekCwnb+ X-Received: by 10.194.158.68 with SMTP id ws4mr18978359wjb.25.1443799132918; Fri, 02 Oct 2015 08:18:52 -0700 (PDT) Received: from cskiralys-MacBook-Air.local ([217.77.82.228]) by smtp.googlemail.com with ESMTPSA id pu6sm11802627wjc.34.2015.10.02.08.18.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2015 08:18:52 -0700 (PDT) From: Csaba Kiraly To: Routing Over Low power and Lossy networks References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> Message-ID: <560EA05A.3080002@fbk.eu> Date: Fri, 2 Oct 2015 17:18:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:18:58 -0000 Hi Pascal, The core observation behind the end-to-end, or delayed ACK (at least on my side, I don't know for Joakim) is that while the one-hop NACK contains important information, the one-hop ACK is not really what you are interested in. In fact, implementations I've checked either don't even ask for it, or if they do, they still don't do anything on a positive ACK. If instead you delay ACKs, or in other words wait for all the parents to ACK, this ACK or NACK brings in an important piece of information. Notice that if your immediate parent would NACK, it would NACK immediately in both interpretations. Feedback only changes where things go well, or things go well till some point on the recursive path, but fail after. In the first, you get an ACK and you know you are reachable. In the latter, you do get to know the problem and you can act upon. Convergence is surely something that needs to be studied carefully, but I think delayed ACK will not create more issues than what you already have with the one-hop ACK. The point that I tried to raise when I brought this up, but maybe it wasn't clear, is that I think both are conformant to RFC6550. Which, if I'm correct, brings me to the point that clarifications might be needed about ACKs in an RFC to avoid interoperability problems, and I think it is needed independent of whether the end-to-end context is a good idea or not. You could even think of sending both types of ACKs, but that would bring the implementation out of RFC6550. Cheers, Csaba On 02/10/15 15:04, Pascal Thubert (pthubert) wrote: > Hello Joakim: > > What I read here boils down to a limited diffusion algorithm. We tried to avoid that in RPL because any movement within the convergence would cause a deadlock. IOW if every node waits for (all of) the parents to ack, then this recursively takes you to the root, and if any node in the chain moves or dies, the diffusion will not be complete. > > Cheers, > > Pascal > >> -----Original Message----- >> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Joakim Eriksson >> Sent: jeudi 1 octobre 2015 22:11 >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] Semantics of DAO ACK >> >> >>> On 01 Oct 2015, at 21:03, Csaba Kiraly wrote: >>> >>> >>> >>> On 30/09/15 17:55, Joakim Eriksson wrote: >>>>> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >>>>> >>>>> Hello Joakim, >>>>> >>>>> I have also worked on the Contiki DAO-ACK code, enabling ACKs, >> implementing fixes to the DAOSequence handling, and looking into multiple >> targets. >>>> Nice, I have a PR on Contiki now with what we have been doing to get >> Contiki RPL more scalable (but still only single targets / paths). >>>>> What Cenk is saying sounds a reasonable hack, but the standard itself >> is in my opinion a bit underspecified for the semantics of DAO-ACK >> messages in several ways. >>>> Yes, it is underspecified. There is need for clarifications and more details >> on the DAO / DAO ACK! >>>>> My preferred solution for ACKing DAO messages with multiple targets >> would be to have support for the same semantics that you would have had >> with one DAO message per Target, i.e., I would prefer an option field that >> gives an individual status for each Target. >>>> Yes, but that would require more memory in the sending node to keep >> track of things or full specification of the target in the response. >>>> I guess it might be solved by allowing multiple DAO ACKs for the same >> DAO and to have the Target options included in the DAO ACK. >>> This is a compromise to consider for sure. If you look at my >> implementation, you can see that I use the routing table entry to match the >> DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not sure it >> would work in all cases, but it did work for the case I considered. I'm >> keeping only the SEQ, and I think this is a must if you have no aggregation, >> and you want to match in case you forward multiple DAOs before getting >> the ACK or timing out on it. In fact, simply enabling ACKs in the original >> code was messing up the match between DAOs and their ACKs because it >> wasn't even keeping track of the DAO sequence numbers. >>> If you do aggregate ACKs, or you have more complex Target+Transit >> scenarios, the game changes, and I don't know what would be the balance >> between state you have to keep anyway and state you keep just to be able >> to interpret a later ACK correctly. I think it is implementation specific, so my >> suggestion would be a flag to indicate whether you request full ACK >> (bumping back all T+T info for rejected entries in the DAO) or a much >> smaller partial ACK with SEQ and similar IDs only. This flag (lets call it F for >> now), could go right next to K. As the DAO propagates, each node could set >> F based on whether it is able to store and/or reproduce info (F not set) or >> chose to remain stateless (set F ). This would exclude aggregation in the >> DAO-ACK sent down, but still allow for aggregation in the DAO sent up. >>>>> To give another example of subtle problems with DAO-ACK, it was not >> clear to me whether I want my implementation to ACK when the Target is >> added to the routing table, or only when this node itself receives an ACK for >> the same Target from its parent. Both makes sense, with the former giving a >> quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring >> that the path is actually built. Both look conformant to the standard, but I >> suppose the original author was thinking of the former, and I can easily see >> interoperability problems arising between two implementations using >> different semantics. >>>> We did go for the end-to-end ACK to achieve better scalability. There >>>> is to me no point having a route to the parent if it is not possible to get >> it all the way to root. But I totally agree - this is not obvious from the RPL >> RFC either. >>> Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in the >> sense that it is still addressed to the next hop but you delay ACK till you >> know your parent (and all its parents) ACKed? >> I mean end-to-end as in waiting for all the parents to ACK so that before >> ACKing it is known that the route is properly installed where it needs to. >> >>>> Do you have your Contiki code somewhere in the open-source? >>> I did some cleanup and pushed the clean part of the code to github: >>> https://github.com/cskiraly/contiki/tree/DAO-NACK >>> It is not yet rebased to the latest master, but it should apply. I suppose >> describing it would be too off-topic for the list. >>> There is also the more experimental part of the code in a PR, if interested. >> Ok - I’ll take a look! >> >> BTW: We have done a few deployments using our implementation using >> Yanzi networks products - take a look at this video where 1000 nodes is >> deployed with Contiki RPL + our fixes and 20 neighbors and routes per >> node. If without our fixes it would not work since Contiki RPL did not allow >> scaling beyond number of neighbors and routes / node that well before >> these fixes. >> >> http://www.yanzi.se/video.jsp?id=7 >> >> Best regards, >> — Joakim Eriksson >> >>> Best regards, >>> Csaba >>>> Best regards, >>>> — Joakim >>>> >>>>> Best regards, >>>>> Csaba >>>>> >>>>> On 29/09/15 23:08, Cenk Gündogan wrote: >>>>>> Hello Joakim, >>>>>> >>>>>> This is an interesting question and I also couldn't find any answers in >> RFC 6550. >>>>>> However, my thoughts on this are as follows: >>>>>> Since a sub-set of the announced RPL targets could have been >>>>>> accepted before filling up the routing table (e.g.), I would choose a >> status code between 1 and 127. >>>>>> I would expect a node to choose another parent if a more aggressive >> status code is received ([128-255]). >>>>>> But a full routing table can have free space again until the next or any >> subsequent DAO arrives .. >>>>>> therefore I prefer a "mild rejection" with a status code of [1-127]. >>>>>> >>>>>> To give some feedback to the originator of the DAO, it might be >>>>>> sensible to copy the rejected RPL Target options from the affected >>>>>> DAO to the DAO-ACK, so that the originator is fully aware of which >> Target prefixes got rejected (and which ones got accepted, implicitly). >>>>>> I would choose this method, because it doesn't require the >>>>>> originator of the DAO to save any extra state about the DAO and its >> contents. >>>>>> Nonetheless, everything I wrote is nonconform and I am also >>>>>> interested in the RPL experts' opinions and solutions. >>>>>> >>>>>> Best, >>>>>> Cenk >>>>>> >>>>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>>>> Hello All, >>>>>>> >>>>>>> I have spend quite some time to get a more stable implementation >>>>>>> of DAO handling for Contiki RPL and I am currently looking into >>>>>>> DAO aggregation. But I realised that it is for me not 100% clear >>>>>>> what a node that receives a DAO with several prefixes to be >>>>>>> registered but can only accept a sub-set of them. Should it be a >> DAO_NACK in this case or is there any other way to handle that case? >>>>>>> If each would have been sent separately it is obvious that the >>>>>>> receiving node can do a NACK when the routing table is full and >>>>>>> therefore it is possible to get fine-grained answers. But with >> aggregation of DAOs this is not the case. >>>>>>> Any ideas? >>>>>>> >>>>>>> Best regards, >>>>>>> — Joakim Eriksson, SICS >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From nobody Fri Oct 2 08:39:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42B1B2C2B for ; Fri, 2 Oct 2015 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZnM6ZOmYH9V for ; Fri, 2 Oct 2015 08:39:42 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB621B2C2A for ; Fri, 2 Oct 2015 08:39:41 -0700 (PDT) Received: by laclj5 with SMTP id lj5so94745086lac.3 for ; Fri, 02 Oct 2015 08:39:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=x8K1sbemnMGLVP69DzggaR4rLDXxYNaHD1NsNNQC6kE=; b=A4NIKcbbkY35j5IY3ar0ykVUz2lGsfTARdj86SmgwCYBCCsDy9RoSNC+NHQPD0mX3y ZlDCM3eRn9fcJ+uatKN6JLlVD6zT7YKiFGEwUS2BEs7I7M17OfFhPAgkHsrl90p5LjnL NpKe9JgvKDwrHg9q5CjhIZPa+VZzABcOB0tqXGn7gCxKmemZxtc0ssAwO4up4GT3gZOR lslTz8zPebeyLdzRaRqc+vxx3bba157JiVFT0sJ2nkLZ18DMPv399cPlkgPQ8Zvlryi1 KWZE9awOy8OAdM38yW6KtAAjuH/l7x7Nx4XX6NgyROvSDeDdY+1rctlw6CyL4mNw4oE+ Okzw== X-Gm-Message-State: ALoCoQliGTvJvyjzUMVVTUKacWlcst3gJydOTaCnlpnlXRhCioDQ+vcJ5Qo6TpuLPvrBUwl+85xX X-Received: by 10.25.167.84 with SMTP id q81mr3991781lfe.124.1443800379252; Fri, 02 Oct 2015 08:39:39 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id g140sm1626662lfg.29.2015.10.02.08.39.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 08:39:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Joakim Eriksson In-Reply-To: <560EA05A.3080002@fbk.eu> Date: Fri, 2 Oct 2015 17:39:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> <560EA05A.3080002@fbk.eu> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:39:45 -0000 =46rom my perspective we really need the end-to-end ACK that is needed - = the single hop ACK is of no use at all if you aim at building scalable RPL networks that have = bi-directional communication. We have worked with this for quite a while at Yanzi Networks and I would = say that if we get a deadlock somewhere that is probably an indication that the selected path/parent = was a bad one and that the node should look for alternatives. If we instead would have gotten a DAO ACK = over single-hop the node would assume connectivity - but be wrong and some other mechanism (usually the = application) needs to kick in and trigger repairs. This is for me not the wanted behaviour and I = rather take the risk of one or a few=20 (short-term) dead-locks if a node in the path towards root reboots or in = other ways is gone. Of course combining DAO ACK (end-to-end) with infinite lifetime routes = is not an optimal configuration if there are many reboots and dead-locks. That is why we try to keep = routing lifetime reasonably short (30 minutes) so that any routes that ended up being =E2=80=9Cstuck=E2=80=9D= somewhere will be garbage collected after a while. Best regards, =E2=80=94 Joakim Eriksson, SICS > On 02 Oct 2015, at 17:18, Csaba Kiraly wrote: >=20 > Hi Pascal, >=20 > The core observation behind the end-to-end, or delayed ACK (at least = on my side, I don't know for Joakim) is that while the one-hop NACK = contains important information, the one-hop ACK is not really what you = are interested in. In fact, implementations I've checked either don't = even ask for it, or if they do, they still don't do anything on a = positive ACK. If instead you delay ACKs, or in other words wait for all = the parents to ACK, this ACK or NACK brings in an important piece of = information. >=20 > Notice that if your immediate parent would NACK, it would NACK = immediately in both interpretations. Feedback only changes where things = go well, or things go well till some point on the recursive path, but = fail after. In the first, you get an ACK and you know you are reachable. = In the latter, you do get to know the problem and you can act upon. = Convergence is surely something that needs to be studied carefully, but = I think delayed ACK will not create more issues than what you already = have with the one-hop ACK. >=20 > The point that I tried to raise when I brought this up, but maybe it = wasn't clear, is that I think both are conformant to RFC6550. Which, if = I'm correct, brings me to the point that clarifications might be needed = about ACKs in an RFC to avoid interoperability problems, and I think it = is needed independent of whether the end-to-end context is a good idea = or not. You could even think of sending both types of ACKs, but that = would bring the implementation out of RFC6550. >=20 > Cheers, > Csaba >=20 > On 02/10/15 15:04, Pascal Thubert (pthubert) wrote: >> Hello Joakim: >>=20 >> What I read here boils down to a limited diffusion algorithm. We = tried to avoid that in RPL because any movement within the convergence = would cause a deadlock. IOW if every node waits for (all of) the parents = to ack, then this recursively takes you to the root, and if any node in = the chain moves or dies, the diffusion will not be complete. >>=20 >> Cheers, >>=20 >> Pascal >>=20 >>> -----Original Message----- >>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Joakim = Eriksson >>> Sent: jeudi 1 octobre 2015 22:11 >>> To: Routing Over Low power and Lossy networks >>> Subject: Re: [Roll] Semantics of DAO ACK >>>=20 >>>=20 >>>> On 01 Oct 2015, at 21:03, Csaba Kiraly wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 30/09/15 17:55, Joakim Eriksson wrote: >>>>>> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >>>>>>=20 >>>>>> Hello Joakim, >>>>>>=20 >>>>>> I have also worked on the Contiki DAO-ACK code, enabling ACKs, >>> implementing fixes to the DAOSequence handling, and looking into = multiple >>> targets. >>>>> Nice, I have a PR on Contiki now with what we have been doing to = get >>> Contiki RPL more scalable (but still only single targets / paths). >>>>>> What Cenk is saying sounds a reasonable hack, but the standard = itself >>> is in my opinion a bit underspecified for the semantics of DAO-ACK >>> messages in several ways. >>>>> Yes, it is underspecified. There is need for clarifications and = more details >>> on the DAO / DAO ACK! >>>>>> My preferred solution for ACKing DAO messages with multiple = targets >>> would be to have support for the same semantics that you would have = had >>> with one DAO message per Target, i.e., I would prefer an option = field that >>> gives an individual status for each Target. >>>>> Yes, but that would require more memory in the sending node to = keep >>> track of things or full specification of the target in the response. >>>>> I guess it might be solved by allowing multiple DAO ACKs for the = same >>> DAO and to have the Target options included in the DAO ACK. >>>> This is a compromise to consider for sure. If you look at my >>> implementation, you can see that I use the routing table entry to = match the >>> DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not = sure it >>> would work in all cases, but it did work for the case I considered. = I'm >>> keeping only the SEQ, and I think this is a must if you have no = aggregation, >>> and you want to match in case you forward multiple DAOs before = getting >>> the ACK or timing out on it. In fact, simply enabling ACKs in the = original >>> code was messing up the match between DAOs and their ACKs because it >>> wasn't even keeping track of the DAO sequence numbers. >>>> If you do aggregate ACKs, or you have more complex Target+Transit >>> scenarios, the game changes, and I don't know what would be the = balance >>> between state you have to keep anyway and state you keep just to be = able >>> to interpret a later ACK correctly. I think it is implementation = specific, so my >>> suggestion would be a flag to indicate whether you request full ACK >>> (bumping back all T+T info for rejected entries in the DAO) or a = much >>> smaller partial ACK with SEQ and similar IDs only. This flag (lets = call it F for >>> now), could go right next to K. As the DAO propagates, each node = could set >>> F based on whether it is able to store and/or reproduce info (F not = set) or >>> chose to remain stateless (set F ). This would exclude aggregation = in the >>> DAO-ACK sent down, but still allow for aggregation in the DAO sent = up. >>>>>> To give another example of subtle problems with DAO-ACK, it was = not >>> clear to me whether I want my implementation to ACK when the Target = is >>> added to the routing table, or only when this node itself receives = an ACK for >>> the same Target from its parent. Both makes sense, with the former = giving a >>> quick one-hop ACK, while the latter works as an end-to-end ACK, = ensuring >>> that the path is actually built. Both look conformant to the = standard, but I >>> suppose the original author was thinking of the former, and I can = easily see >>> interoperability problems arising between two implementations using >>> different semantics. >>>>> We did go for the end-to-end ACK to achieve better scalability. = There >>>>> is to me no point having a route to the parent if it is not = possible to get >>> it all the way to root. But I totally agree - this is not obvious = from the RPL >>> RFC either. >>>> Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in = the >>> sense that it is still addressed to the next hop but you delay ACK = till you >>> know your parent (and all its parents) ACKed? >>> I mean end-to-end as in waiting for all the parents to ACK so that = before >>> ACKing it is known that the route is properly installed where it = needs to. >>>=20 >>>>> Do you have your Contiki code somewhere in the open-source? >>>> I did some cleanup and pushed the clean part of the code to github: >>>> https://github.com/cskiraly/contiki/tree/DAO-NACK >>>> It is not yet rebased to the latest master, but it should apply. I = suppose >>> describing it would be too off-topic for the list. >>>> There is also the more experimental part of the code in a PR, if = interested. >>> Ok - I=E2=80=99ll take a look! >>>=20 >>> BTW: We have done a few deployments using our implementation using >>> Yanzi networks products - take a look at this video where 1000 nodes = is >>> deployed with Contiki RPL + our fixes and 20 neighbors and routes = per >>> node. If without our fixes it would not work since Contiki RPL did = not allow >>> scaling beyond number of neighbors and routes / node that well = before >>> these fixes. >>>=20 >>> http://www.yanzi.se/video.jsp?id=3D7 >>>=20 >>> Best regards, >>> =E2=80=94 Joakim Eriksson >>>=20 >>>> Best regards, >>>> Csaba >>>>> Best regards, >>>>> =E2=80=94 Joakim >>>>>=20 >>>>>> Best regards, >>>>>> Csaba >>>>>>=20 >>>>>> On 29/09/15 23:08, Cenk G=C3=BCndogan wrote: >>>>>>> Hello Joakim, >>>>>>>=20 >>>>>>> This is an interesting question and I also couldn't find any = answers in >>> RFC 6550. >>>>>>> However, my thoughts on this are as follows: >>>>>>> Since a sub-set of the announced RPL targets could have been >>>>>>> accepted before filling up the routing table (e.g.), I would = choose a >>> status code between 1 and 127. >>>>>>> I would expect a node to choose another parent if a more = aggressive >>> status code is received ([128-255]). >>>>>>> But a full routing table can have free space again until the = next or any >>> subsequent DAO arrives .. >>>>>>> therefore I prefer a "mild rejection" with a status code of = [1-127]. >>>>>>>=20 >>>>>>> To give some feedback to the originator of the DAO, it might be >>>>>>> sensible to copy the rejected RPL Target options from the = affected >>>>>>> DAO to the DAO-ACK, so that the originator is fully aware of = which >>> Target prefixes got rejected (and which ones got accepted, = implicitly). >>>>>>> I would choose this method, because it doesn't require the >>>>>>> originator of the DAO to save any extra state about the DAO and = its >>> contents. >>>>>>> Nonetheless, everything I wrote is nonconform and I am also >>>>>>> interested in the RPL experts' opinions and solutions. >>>>>>>=20 >>>>>>> Best, >>>>>>> Cenk >>>>>>>=20 >>>>>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>>>>> Hello All, >>>>>>>>=20 >>>>>>>> I have spend quite some time to get a more stable = implementation >>>>>>>> of DAO handling for Contiki RPL and I am currently looking into >>>>>>>> DAO aggregation. But I realised that it is for me not 100% = clear >>>>>>>> what a node that receives a DAO with several prefixes to be >>>>>>>> registered but can only accept a sub-set of them. Should it be = a >>> DAO_NACK in this case or is there any other way to handle that case? >>>>>>>> If each would have been sent separately it is obvious that the >>>>>>>> receiving node can do a NACK when the routing table is full and >>>>>>>> therefore it is possible to get fine-grained answers. But with >>> aggregation of DAOs this is not the case. >>>>>>>> Any ideas? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>> =E2=80=94 Joakim Eriksson, SICS >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Oct 2 21:41:14 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C171B346C for ; Fri, 2 Oct 2015 21:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJZJgFXOVKFE for ; Fri, 2 Oct 2015 21:41:09 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462BF1B3466 for ; Fri, 2 Oct 2015 21:41:09 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so53186044wic.1 for ; Fri, 02 Oct 2015 21:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8qZc+vsOHqh6/EnITTxjDI+YUdmIiVnp+VSZaji5pOQ=; b=GgI9iJS3fGSqGlF+2NRzmSzHh45s0PkZ8/jygiyGVzcOiWDqIUXvWCy21oxKr+uhN1 DKnDpJivXveqhyc+l/kxjiij1Mjp7Z87xTE8bIwXSXSh8UjbRUYb52zbdCFaMDkPyZ7B rkNPHMa+fS2UOikG9ExVXjnQFV4zu3/5LH1dnINodg2gq4aVLSxeRfPqAvDJiWHFpmrq NCyyuIoKUQya52n9gMs6M+1bQFon66ROW1dDDXGL9sB/3oUv5bE3gYm/WTr7e+C5eEZu YkCGFvidvPOddTt46paTSeu5nPYbkhjrLBG5Yzkq4X8x4G2d3xzxMHREwMQeEDdJ/YDK +tVw== X-Gm-Message-State: ALoCoQkHpvj3oyEeBBzksbmJP/3X1/YKy/mX+1htM0ohI21Sx8uRY2MpiMNdJxfoPOxPlA9YxgEonIB6KEXP1lYAOSRn9Qi+Hx7ZTkEUbzCWCMb0l/SUeYVFWG1I0F/ktc0lCJzIz2Rmmiga4ITEqP4BncprgUd++1HHv3TwX5IY/hc3Xz+OGxg= X-Received: by 10.194.22.69 with SMTP id b5mr18755992wjf.157.1443847267618; Fri, 02 Oct 2015 21:41:07 -0700 (PDT) Received: from cskiralys-MacBook-Air.local (host8-109-dynamic.21-79-r.retail.telecomitalia.it. [79.21.109.8]) by smtp.googlemail.com with ESMTPSA id gt4sm2133105wib.21.2015.10.02.21.41.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2015 21:41:06 -0700 (PDT) To: roll@ietf.org References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> <560EA05A.3080002@fbk.eu> From: Csaba Kiraly Message-ID: <560F5C5E.8010806@fbk.eu> Date: Sat, 3 Oct 2015 06:41:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 04:41:13 -0000 Since we were jumping through several topics around the DAO-ACK semantics in this thread, I wrote a quick memo of what had been brought up till now. I thought it might worth sharing: DAO-ACK semantics ----------------- 1, ACK for DAO with multiple T+T [Joakim] - status code 1-127, and copy rejected Target [Cenk] - new option with individual status codes (same semantics as with multiple individual messages) [Csaba] - send individual ACKs for each Target [Joakim] - memory concerns, better to include Target in response [Joakim] - “F” flag in DAO to request full ACK with T+T or partial ACK with status codes only [Csaba] - meaning of status code [Pascal] - enumeration - both Joakim and we use this (not for multiple T+T, but to differentiate different reasons of DAO rejection) - would need registry for interoperability [Pascal] - metric: as “scalar degree of unwillingness” calculated based on available resources [Pascal] - could be difficult to combine it into one scalar degree in one byte [Joakim, Csaba] - might be better to put the resource info in DIO or in a DAO option [Csaba] - ACK with rejected T+T and status code for each; relation to path control [Pascal] - “All-or-nothing” flag in DAO [Joakim] 2, ACK semantics: one-hop vs. end-to-end context [Csaba] - when speaking of end-to-end context, we do not refer to a DAO addressed directly to the root, like in non-storing, but to a different interpretation of the ACK of the one-hop DAO [Csaba, Joakim] - used in Yanzi [Joakim] - drafted advantages and disadvantages [Pascal, Csaba, Joakim] - possible deadlock [Pascal] - is it RFC6550? - one-hop ACK is not enough info, needs end-to-end for decision logic [Csaba, Joakim] 3, fix meaning of status code 127 (just a typo in the RFC) [Csaba] 4, status code in ACK for No-path DAO not defined clearly [Csaba] - only code 0 makes sense [Joakim] - not using end-to-end context in this case [Joakim] 5, multiple DAO ACKs for same DAO [Joakim, Csaba] - to handle multiple T+T [Joakim] - to have both end-to-end and one-hop ACK semantics [Csaba] Disclaimer: this doesn't want to be a full summary, and I obviously skipped many detail in such a brief writeup. Cheers, Csaba On 02/10/15 17:39, Joakim Eriksson wrote: > From my perspective we really need the end-to-end ACK that is needed - the single hop ACK is > of no use at all if you aim at building scalable RPL networks that have bi-directional communication. > > We have worked with this for quite a while at Yanzi Networks and I would say that if we get a deadlock > somewhere that is probably an indication that the selected path/parent was a bad one and that the node > should look for alternatives. If we instead would have gotten a DAO ACK over single-hop the node would > assume connectivity - but be wrong and some other mechanism (usually the application) needs to kick in > and trigger repairs. This is for me not the wanted behaviour and I rather take the risk of one or a few > (short-term) dead-locks if a node in the path towards root reboots or in other ways is gone. > > Of course combining DAO ACK (end-to-end) with infinite lifetime routes is not an optimal configuration > if there are many reboots and dead-locks. That is why we try to keep routing lifetime reasonably short > (30 minutes) so that any routes that ended up being “stuck” somewhere will be garbage collected after > a while. > > Best regards, > — Joakim Eriksson, SICS > > >> On 02 Oct 2015, at 17:18, Csaba Kiraly wrote: >> >> Hi Pascal, >> >> The core observation behind the end-to-end, or delayed ACK (at least on my side, I don't know for Joakim) is that while the one-hop NACK contains important information, the one-hop ACK is not really what you are interested in. In fact, implementations I've checked either don't even ask for it, or if they do, they still don't do anything on a positive ACK. If instead you delay ACKs, or in other words wait for all the parents to ACK, this ACK or NACK brings in an important piece of information. >> >> Notice that if your immediate parent would NACK, it would NACK immediately in both interpretations. Feedback only changes where things go well, or things go well till some point on the recursive path, but fail after. In the first, you get an ACK and you know you are reachable. In the latter, you do get to know the problem and you can act upon. Convergence is surely something that needs to be studied carefully, but I think delayed ACK will not create more issues than what you already have with the one-hop ACK. >> >> The point that I tried to raise when I brought this up, but maybe it wasn't clear, is that I think both are conformant to RFC6550. Which, if I'm correct, brings me to the point that clarifications might be needed about ACKs in an RFC to avoid interoperability problems, and I think it is needed independent of whether the end-to-end context is a good idea or not. You could even think of sending both types of ACKs, but that would bring the implementation out of RFC6550. >> >> Cheers, >> Csaba >> >> On 02/10/15 15:04, Pascal Thubert (pthubert) wrote: >>> Hello Joakim: >>> >>> What I read here boils down to a limited diffusion algorithm. We tried to avoid that in RPL because any movement within the convergence would cause a deadlock. IOW if every node waits for (all of) the parents to ack, then this recursively takes you to the root, and if any node in the chain moves or dies, the diffusion will not be complete. >>> >>> Cheers, >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Joakim Eriksson >>>> Sent: jeudi 1 octobre 2015 22:11 >>>> To: Routing Over Low power and Lossy networks >>>> Subject: Re: [Roll] Semantics of DAO ACK >>>> >>>> >>>>> On 01 Oct 2015, at 21:03, Csaba Kiraly wrote: >>>>> >>>>> >>>>> >>>>> On 30/09/15 17:55, Joakim Eriksson wrote: >>>>>>> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >>>>>>> >>>>>>> Hello Joakim, >>>>>>> >>>>>>> I have also worked on the Contiki DAO-ACK code, enabling ACKs, >>>> implementing fixes to the DAOSequence handling, and looking into multiple >>>> targets. >>>>>> Nice, I have a PR on Contiki now with what we have been doing to get >>>> Contiki RPL more scalable (but still only single targets / paths). >>>>>>> What Cenk is saying sounds a reasonable hack, but the standard itself >>>> is in my opinion a bit underspecified for the semantics of DAO-ACK >>>> messages in several ways. >>>>>> Yes, it is underspecified. There is need for clarifications and more details >>>> on the DAO / DAO ACK! >>>>>>> My preferred solution for ACKing DAO messages with multiple targets >>>> would be to have support for the same semantics that you would have had >>>> with one DAO message per Target, i.e., I would prefer an option field that >>>> gives an individual status for each Target. >>>>>> Yes, but that would require more memory in the sending node to keep >>>> track of things or full specification of the target in the response. >>>>>> I guess it might be solved by allowing multiple DAO ACKs for the same >>>> DAO and to have the Target options included in the DAO ACK. >>>>> This is a compromise to consider for sure. If you look at my >>>> implementation, you can see that I use the routing table entry to match the >>>> DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not sure it >>>> would work in all cases, but it did work for the case I considered. I'm >>>> keeping only the SEQ, and I think this is a must if you have no aggregation, >>>> and you want to match in case you forward multiple DAOs before getting >>>> the ACK or timing out on it. In fact, simply enabling ACKs in the original >>>> code was messing up the match between DAOs and their ACKs because it >>>> wasn't even keeping track of the DAO sequence numbers. >>>>> If you do aggregate ACKs, or you have more complex Target+Transit >>>> scenarios, the game changes, and I don't know what would be the balance >>>> between state you have to keep anyway and state you keep just to be able >>>> to interpret a later ACK correctly. I think it is implementation specific, so my >>>> suggestion would be a flag to indicate whether you request full ACK >>>> (bumping back all T+T info for rejected entries in the DAO) or a much >>>> smaller partial ACK with SEQ and similar IDs only. This flag (lets call it F for >>>> now), could go right next to K. As the DAO propagates, each node could set >>>> F based on whether it is able to store and/or reproduce info (F not set) or >>>> chose to remain stateless (set F ). This would exclude aggregation in the >>>> DAO-ACK sent down, but still allow for aggregation in the DAO sent up. >>>>>>> To give another example of subtle problems with DAO-ACK, it was not >>>> clear to me whether I want my implementation to ACK when the Target is >>>> added to the routing table, or only when this node itself receives an ACK for >>>> the same Target from its parent. Both makes sense, with the former giving a >>>> quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring >>>> that the path is actually built. Both look conformant to the standard, but I >>>> suppose the original author was thinking of the former, and I can easily see >>>> interoperability problems arising between two implementations using >>>> different semantics. >>>>>> We did go for the end-to-end ACK to achieve better scalability. There >>>>>> is to me no point having a route to the parent if it is not possible to get >>>> it all the way to root. But I totally agree - this is not obvious from the RPL >>>> RFC either. >>>>> Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in the >>>> sense that it is still addressed to the next hop but you delay ACK till you >>>> know your parent (and all its parents) ACKed? >>>> I mean end-to-end as in waiting for all the parents to ACK so that before >>>> ACKing it is known that the route is properly installed where it needs to. >>>> >>>>>> Do you have your Contiki code somewhere in the open-source? >>>>> I did some cleanup and pushed the clean part of the code to github: >>>>> https://github.com/cskiraly/contiki/tree/DAO-NACK >>>>> It is not yet rebased to the latest master, but it should apply. I suppose >>>> describing it would be too off-topic for the list. >>>>> There is also the more experimental part of the code in a PR, if interested. >>>> Ok - I’ll take a look! >>>> >>>> BTW: We have done a few deployments using our implementation using >>>> Yanzi networks products - take a look at this video where 1000 nodes is >>>> deployed with Contiki RPL + our fixes and 20 neighbors and routes per >>>> node. If without our fixes it would not work since Contiki RPL did not allow >>>> scaling beyond number of neighbors and routes / node that well before >>>> these fixes. >>>> >>>> http://www.yanzi.se/video.jsp?id=7 >>>> >>>> Best regards, >>>> — Joakim Eriksson >>>> >>>>> Best regards, >>>>> Csaba >>>>>> Best regards, >>>>>> — Joakim >>>>>> >>>>>>> Best regards, >>>>>>> Csaba >>>>>>> >>>>>>> On 29/09/15 23:08, Cenk Gündogan wrote: >>>>>>>> Hello Joakim, >>>>>>>> >>>>>>>> This is an interesting question and I also couldn't find any answers in >>>> RFC 6550. >>>>>>>> However, my thoughts on this are as follows: >>>>>>>> Since a sub-set of the announced RPL targets could have been >>>>>>>> accepted before filling up the routing table (e.g.), I would choose a >>>> status code between 1 and 127. >>>>>>>> I would expect a node to choose another parent if a more aggressive >>>> status code is received ([128-255]). >>>>>>>> But a full routing table can have free space again until the next or any >>>> subsequent DAO arrives .. >>>>>>>> therefore I prefer a "mild rejection" with a status code of [1-127]. >>>>>>>> >>>>>>>> To give some feedback to the originator of the DAO, it might be >>>>>>>> sensible to copy the rejected RPL Target options from the affected >>>>>>>> DAO to the DAO-ACK, so that the originator is fully aware of which >>>> Target prefixes got rejected (and which ones got accepted, implicitly). >>>>>>>> I would choose this method, because it doesn't require the >>>>>>>> originator of the DAO to save any extra state about the DAO and its >>>> contents. >>>>>>>> Nonetheless, everything I wrote is nonconform and I am also >>>>>>>> interested in the RPL experts' opinions and solutions. >>>>>>>> >>>>>>>> Best, >>>>>>>> Cenk >>>>>>>> >>>>>>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> I have spend quite some time to get a more stable implementation >>>>>>>>> of DAO handling for Contiki RPL and I am currently looking into >>>>>>>>> DAO aggregation. But I realised that it is for me not 100% clear >>>>>>>>> what a node that receives a DAO with several prefixes to be >>>>>>>>> registered but can only accept a sub-set of them. Should it be a >>>> DAO_NACK in this case or is there any other way to handle that case? >>>>>>>>> If each would have been sent separately it is obvious that the >>>>>>>>> receiving node can do a NACK when the routing table is full and >>>>>>>>> therefore it is possible to get fine-grained answers. But with >>>> aggregation of DAOs this is not the case. >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> — Joakim Eriksson, SICS >>>>>>>>> _______________________________________________ >>>>>>>>> Roll mailing list >>>>>>>>> Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Oct 9 04:54:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366871B38A2 for ; Fri, 9 Oct 2015 04:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsT2er2CdUsM for ; Fri, 9 Oct 2015 04:54:44 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6A01B38A0 for ; Fri, 9 Oct 2015 04:54:43 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so66959278wic.1 for ; Fri, 09 Oct 2015 04:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=6i2lb9KJ3V/737cVaKX5/fQZttvuaHrLFHARJttEYTY=; b=eOT1URAt5ildF4xnS1508FYUN2FMWZNf63FTa/eD020mEcIDiwdcM0vAXYUQ7dFIy+ ayzk82stEjUyj8zHaky8+lg0a2Eo0BFYLje4ZfNvT2u+E3TAGCbT+8iSzuOt8UjuYqD6 uIJkrPSNGePid0CaO0XgKg/aCYKECCDElcgaOrceRDFEMiZBkIVaqGsBEVnL4o4r2q8G PnotqiaK+t9Hj2uQVvQHn8oOp+GA9aRaFJcpR2s1rjUEp+xTU7Nij6KAf8UunXIzsUTY eTpo5+gW7lTIaUzDFj5PLaaKWLxKepXyGrryshe2mhF+O+wjzcZBdlgHGi/3VufmJaQO zV2A== X-Received: by 10.194.242.167 with SMTP id wr7mr14036646wjc.27.1444391682393; Fri, 09 Oct 2015 04:54:42 -0700 (PDT) Received: from [10.92.124.3] (z5c7c.pia.fu-berlin.de. [87.77.92.124]) by smtp.googlemail.com with ESMTPSA id ka10sm1672865wjc.30.2015.10.09.04.54.41 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Oct 2015 04:54:41 -0700 (PDT) To: Routing Over Low power and Lossy networks From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <5617AB01.7060703@gmail.com> Date: Fri, 9 Oct 2015 13:54:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Roll] RPL-aware or not RPL-aware, that's the question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 11:54:45 -0000 Hello *, I was hoping to find some answers to the question of how to know if a target is within a RPL-domain or not. The rationale is that this knowledge is needed to decide if an IP-in-IP encapsulation is needed or not for several use cases using the RPI header. The last virtual interim meeting successfully identified these use cases and perpetuated them in the ether pad [1]. AFAIK, there is no standard compliant way to announce routes in the RPL-domain as routes being established through RPL DAOs or by other means. I guess this information could be propagated using one of the Reserved1 flags form the Prefix Information Option, or by using a specific descriptior in the RPL Descriptor Option (?). But such kind of propagation would still fail for traffic flows from a RPL-aware node to a common RPL parent and down to an arbitrary node (no matter if RPL-aware or not), because the source node has no information about the state of that arbitrary node. Does anyone know how to handle this case? Best, Cenk [1] http://etherpad.tools.ietf.org:9000/p/ROLL-Interim_Meeting_-09-29-2015 From nobody Sat Oct 10 05:15:51 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863701A8ABB; Sat, 10 Oct 2015 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLiKOqS5JsuV; Sat, 10 Oct 2015 05:15:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F971A8ABA; Sat, 10 Oct 2015 05:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9ACFdtl013818; Sat, 10 Oct 2015 14:15:39 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nY4wq0CMCz4pK6; Sat, 10 Oct 2015 14:15:38 +0200 (CEST) Message-ID: <56190169.3050003@tzi.org> Date: Sat, 10 Oct 2015 14:15:37 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: lwip@ietf.org, 6tisch@ietf.org, roll@ietf.org, 6lo@ietf.org, t2trg@ietf.org References: <5618FF18.8050909@tzi.org> In-Reply-To: <5618FF18.8050909@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Roll] Fwd: Constrained Node/Network Cluster @ IETF94, "final" version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 12:15:44 -0000 Sorry for the duplicate posting, the IETF mail system does not allow sending to all 9 mailing lists at the same time. -------- Original Message -------- Subject: Constrained Node/Network Cluster @ IETF94, "final" version Date: Sat, 10 Oct 2015 14:05:44 +0200 From: Carsten Bormann To: dtls-iot@ietf.org, core@ietf.org, ace@ietf.org, cose@ietf.org, t2trg@irtf.org Below is the "final" version of my usual eclectic condensed agenda. (Sorry for missing out on the draft version, but not much has changed.) Again, I have filled in the T2TRG Sat/Sun meeting, which is waiting for its room assignment; the T2TRG summary meeting this time is on Wed morning (and we have 1 h, which should be enough for a summary). Remember that there is still some potential for changes. All times are JST (UTC+0900) (the browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote). Grüße, Carsten SATURDAY, October 31, 2015 0900-1830 T2TRG - Room TBD 0900-2100 IETF Hackathon - Room 315 0900-1830 RAIM Workshop - Room 303 SUNDAY, November 1, 2015 0900-1600 T2TRG - Room TBD 0900-1800 IETF Hackathon - Room 315 1600-1700 Newcomers' Meet and Greet (open to Newcomers, WG chairs and Mentors only) - InterContinental Bay View Room 1600-1630 CBOR - Room 301 1700-1900 Welcome Reception - InterContinental Ballroom MONDAY, November 2, 2015 0900-1130 Morning Session I Rm 501 OPS v6ops IPv6 Operations WG Rm 301 RTG detnet Deterministic Networking WG Rm 302 SEC *** ace Authentication and Authorization for Constrained Environments WG 1300-1500 Afternoon Session I Rm 501 ART httpbis Hypertext Transfer Protocol WG Rm 304 OPS anima Autonomic Networking Integrated Model and Approach WG Rm 303 TSV tsvwg Transport Area Working Group WG 1520-1650 Afternoon Session II Rm 302 INT dnssd Extensions for Scalable DNS Service Discovery WG Rm 501 TSV rmcat RTP Media Congestion Avoidance Techniques WG 1710-1910 Afternoon Session III Rm 502 OPS v6ops IPv6 Operations WG Rm 501 RTG rtgarea Routing Area Open Meeting Rm 302 SEC tokbind Token Binding WG TUESDAY, November 3, 2015 0900-1130 Morning Session I Rm 301 ART *** core Constrained RESTful Environments WG Rm 502 INT homenet Home Networking WG 1300-1500 Afternoon Session I 411/412 ART webpush Web-Based Push Notifications WG 1520-1650 Afternoon Session II Rm 303 OPS anima Autonomic Networking Integrated Model and Approach WG Rm 413 SEC *** cose CBOR Object Signing and Encryption WG Rm 304 TSV taps Transport Services WG 1710-1840 Afternoon Session III 411/412 SEC openpgp Open Specification for Pretty Good Privacy WG WEDNESDAY, November 4, 2015 0900-1130 Morning Session I Rm 501 INT 6man IPv6 Maintenance WG Rm 302 IRTF*** t2trg Proposed Thing-to-Thing Research Group - 1030 - 1130 Rm 303 SEC tls Transport Layer Security WG 1300-1500 Afternoon Session I Rm 501 TSV tcpinc TCP Increased Security WG THURSDAY, November 5, 2015 0900-1130 Morning Session I Rm 303 ART ice Interactive Connectivity Establishment WG Rm 501 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG 1300-1500 Afternoon Session I Rm 413 ART geojson Geographic JSON WG Rm 502 SEC saag Security Area Open Meeting Rm 302 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Rm 303 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Rm 501 OPS opsarea Operations & Management Area Open Meeting - Combined with OPSAWG Rm 301 SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Rm 304 INT intarea Internet Area Working Group WG Rm 302 RTG *** roll Routing Over Low power and Lossy networks WG Rm 501 SEC tls Transport Layer Security WG FRIDAY, November 6, 2015 0900-1130 Morning Session I Rm 302 ART *** core Constrained RESTful Environments WG 411/412 RTG bier Bit Indexed Explicit Replication WG Rm 304 SEC acme Automated Certificate Management Environment WG Rm 501 TSV rmcat RTP Media Congestion Avoidance Techniques WG All day ETSI 6lo Plugtest SATURDAY, November 7, 2015 All day ETSI 6lo Plugtest SUNDAY, November 8, 2015 All day ETSI 6lo Plugtest From nobody Thu Oct 15 08:06:15 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56F61A8892 for ; Thu, 15 Oct 2015 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82EL10zq7hot for ; Thu, 15 Oct 2015 08:06:11 -0700 (PDT) Received: from zeed.gatineau.credil.org (smtp.linguistech.ca [IPv6:2001:4978:2ad:8::115]) by ietfa.amsl.com (Postfix) with ESMTP id 848711A888F for ; Thu, 15 Oct 2015 08:06:11 -0700 (PDT) Received: from [IPv6:2607:f0b0:f:2::247] (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by zeed.gatineau.credil.org (Postfix) with ESMTPA id E416E26733 for ; Thu, 15 Oct 2015 11:06:07 -0400 (EDT) Message-ID: <561FC0DE.8030504@sandelman.ca> Date: Thu, 15 Oct 2015 11:06:06 -0400 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> In-Reply-To: <560B68B2.6030501@fbk.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:06:13 -0000 On 09/30/15 00:44, Csaba Kiraly wrote: > What Cenk is saying sounds a reasonable hack, but the standard itself > is in my opinion a bit underspecified for the semantics of DAO-ACK > messages in several ways. I think that a document that updates RFC6550 would be very welcome, even if it just describes this single issue. I think it is premature to consider revising/advance RFC6550 from PS to Internet Standard, but a series of small updates would make that activity significantly easier. (trying to post via Thunderbird from new IMAP list access) From nobody Thu Oct 15 08:11:43 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E71A8844 for ; Thu, 15 Oct 2015 08:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNGiaEkfpSrO for ; Thu, 15 Oct 2015 08:11:41 -0700 (PDT) Received: from zeed.gatineau.credil.org (smtp.linguistech.ca [IPv6:2001:4978:2ad:8::115]) by ietfa.amsl.com (Postfix) with ESMTP id 534211A896D for ; Thu, 15 Oct 2015 08:11:41 -0700 (PDT) Received: from [IPv6:2607:f0b0:f:2::247] (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by zeed.gatineau.credil.org (Postfix) with ESMTPA id D074226733 for ; Thu, 15 Oct 2015 11:11:40 -0400 (EDT) Message-ID: <561FC22C.6000000@sandelman.ca> Date: Thu, 15 Oct 2015 11:11:40 -0400 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: roll@ietf.org References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> In-Reply-To: <560B68B2.6030501@fbk.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:11:42 -0000 On 09/30/15 00:44, Csaba Kiraly wrote: > What Cenk is saying sounds a reasonable hack, but the standard itself > is in my opinion a bit underspecified for the semantics of DAO-ACK > messages in several ways. A document which updated RFC6550 would be welcome here. From nobody Thu Oct 15 08:13:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84151A896F for ; Thu, 15 Oct 2015 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDssjzF3qGXD for ; Thu, 15 Oct 2015 08:13:42 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8374D1B3354 for ; Thu, 15 Oct 2015 08:13:38 -0700 (PDT) Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1077.eurprd01.prod.exchangelabs.com (10.162.152.14) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 15 Oct 2015 15:13:22 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0300.010; Thu, 15 Oct 2015 15:13:22 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Semantics of DAO ACK Thread-Index: AQHQ+zq5HB57FLIULka3JvejKN+0pZ5swSAAgAAAMSA= Date: Thu, 15 Oct 2015 15:13:22 +0000 Message-ID: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <561FC22C.6000000@sandelman.ca> In-Reply-To: <561FC22C.6000000@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.144] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1077; 5:j6eexZ0bh//cSmNwyERIoDZxTk64vLZ4fw/8otsoeQL7wGQSl07KKlNxsQY0hz7Hcp9XpCBQcZDlvSW0qLPNKcUak98YTyJfH06idjLb1LPWWtFoH2DwApZi2g60+C4kvx/IOiy5BUHOLRJjUmkzOw==; 24:xdEpr7u8BBSQQog4xUcSfsu7d7qUjSS7tqYitmcMWXk+mFiS869qnNAPIr7ZUcPadKJDNnRk2pkybnu6CtZQkAvJRagRnsIe40nV09mpFmM=; 20:ogKVPNPG6/cyLDEMTsmdtMrtnoXeQUVwO4WHrRV3xeufvMV43Z+LiSJs+jy55H55PROkeCpgWTk/REGxnl+jnw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1077; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:DB5PR01MB1077; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1077; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(479174004)(377454003)(13464003)(189998001)(2950100001)(19580405001)(5003600100002)(19580395003)(86362001)(2900100001)(102836002)(15975445007)(40100003)(77096005)(87936001)(93886004)(81156007)(106116001)(106356001)(105586002)(5002640100001)(50986999)(54356999)(76176999)(33656002)(97736004)(10400500002)(110136002)(107886002)(5001960100002)(66066001)(101416001)(46102003)(74316001)(122556002)(11100500001)(450100001)(5008740100001)(5004730100002)(92566002)(5007970100001)(5890100001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1077; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 15:13:22.3986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1077 Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:13:45 -0000 There are already a number of inter-related RFCs to effectively implement R= PL - maybe a "bis" or taxonomy that lays out a roadmap for implementation. +1 Randy -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Thursday, October 15, 2015 11:12 AM To: roll@ietf.org Subject: Re: [Roll] Semantics of DAO ACK On 09/30/15 00:44, Csaba Kiraly wrote: > What Cenk is saying sounds a reasonable hack, but the standard itself > is in my opinion a bit underspecified for the semantics of DAO-ACK > messages in several ways. A document which updated RFC6550 would be welcome here. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. From nobody Thu Oct 15 08:23:03 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09F1A9141 for ; Thu, 15 Oct 2015 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUf5hILp9pHz for ; Thu, 15 Oct 2015 08:22:59 -0700 (PDT) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA1C1A90EB for ; Thu, 15 Oct 2015 08:22:59 -0700 (PDT) Received: by lffv3 with SMTP id v3so32302650lff.0 for ; Thu, 15 Oct 2015 08:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=gj3OsmyatIX/7lKdcw4Yh992cYFhgP7JUb9qv/HOcXY=; b=IwYfoVRoW4p11XOd8CcOQN+mbXnSfcpqFv6P7ajyokHjGz5rGADOY1vlr4BGFf1Yke pu8Wgy2AVYLGlOUf9GlnZVQP7VICe2018XyiotxTVvBo78OgXKrmVM88usnZmqkx+K7q /2isugEztJLm2uYOt5/vDrjOEeZyaWigUNNNfB33wtJJoCjSZz4+dpC2mjNLHb0nkC6e 9EtGrWqBnXTk4oD2bkv6MZ8ImaGUVtwSoXqJB70OLGHgxSvlMg3ULKZB3AdrxIZUorZl xVumaYrlP23cyfKx2lfAuHNTCWvdnRZIgDoAKvw+xxMXdqeGUhKkRVnmJ1k1B31Sd4ww gI9w== X-Gm-Message-State: ALoCoQlsN9tu5QB9BHroXSpg89JyRpPn3MOgMiA8ZKFxl+ogh1BekR6iEHdB6xcaMVs/I+Ptba3qd0IUkRdtTfCEiJcQN2ORW4Po09RhiXEwP5hByd/YupheCJR9/SWiCjTunW73QGdoGvPMnitP8EwKEIx2RU3iyVz5cIB1kySoR3pWuuAyASE= X-Received: by 10.180.184.232 with SMTP id ex8mr11198038wic.15.1444922577575; Thu, 15 Oct 2015 08:22:57 -0700 (PDT) Received: from cskiralys-MacBook-Air.local ([217.77.82.234]) by smtp.googlemail.com with ESMTPSA id m6sm11837916wif.11.2015.10.15.08.22.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 08:22:56 -0700 (PDT) To: roll@ietf.org References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <561FC22C.6000000@sandelman.ca> From: Csaba Kiraly Message-ID: <561FC4CD.4040508@fbk.eu> Date: Thu, 15 Oct 2015 17:22:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561FC22C.6000000@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:23:02 -0000 On 15/10/15 17:11, Michael Richardson wrote: > > > On 09/30/15 00:44, Csaba Kiraly wrote: >> What Cenk is saying sounds a reasonable hack, but the standard itself >> is in my opinion a bit underspecified for the semantics of DAO-ACK >> messages in several ways. > > A document which updated RFC6550 would be welcome here. I could extend my previous summary into a more proper document, but I have no experience with RFC writing, so I would prefer to team up with someone who is more knowledgeable in the writing style. Anyone willing to help? Csaba > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 15 10:01:08 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DFA1A88A1 for ; Thu, 15 Oct 2015 10:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Ht9TQlTk77 for ; Thu, 15 Oct 2015 10:00:57 -0700 (PDT) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65311A6FA9 for ; Thu, 15 Oct 2015 10:00:56 -0700 (PDT) Received: by lffv3 with SMTP id v3so37018002lff.0 for ; Thu, 15 Oct 2015 10:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Rkxk9hR5pKZrj43tD2mWpHoih5nYocbyPYlPQML5dak=; b=dCTZHF/PP8a7BgXMwHkGRogR4lDpDOnh9PRk/R72b0W0aASH0Fh5CaBsHLk3HOxISi eaKgODPaURBB5XurwJdtdy1OAIGZIWAyx6Aw0eLZyzHVLQyXD8RYjGEPKlwoMuPjjdst N0FB+qCkh1we4j7Oigut3yeUwSmr0s/H6WediRyAxkHroCq9cE2WnxoOcczl/Le91NAp 69WJ6DmLkldKMWsDVAFIPmchBSTn6lSNKOgyePy7fMDSuwNbF5gM8jYT3k1GFkFj7GPm PqXwZzEBa5taWc59jIXh24IQ58trVLjdvJCCL4blxx8M2EKDQRbxW5iw+2S5bpYtak5i tD+g== X-Gm-Message-State: ALoCoQlUzzkE2OHvGxWlgiHHkwXDd+6yVPQrpoJljsn35ZQRo06nZnPURdQx+9TVkdfU1GcM0b4J X-Received: by 10.25.165.4 with SMTP id o4mr3450330lfe.4.1444928454081; Thu, 15 Oct 2015 10:00:54 -0700 (PDT) Received: from [192.168.1.102] (h31n15-sbg-a11.ias.bredband.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id b140sm2208600lfe.23.2015.10.15.10.00.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 10:00:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Joakim Eriksson In-Reply-To: <561FC4CD.4040508@fbk.eu> Date: Thu, 15 Oct 2015 19:00:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3719B311-73DD-4526-AC2C-4871F2573963@sics.se> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <561FC22C.6000000@sandelman.ca> <561FC4CD.4040508@fbk.eu> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3094) Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:01:02 -0000 Hello, I am planning to help out to write our DAO ACK experiences down in an = RFC! Best regards, =E2=80=94 Joakim > On 15 Oct 2015, at 17:22, Csaba Kiraly wrote: >=20 >=20 >=20 > On 15/10/15 17:11, Michael Richardson wrote: >>=20 >>=20 >> On 09/30/15 00:44, Csaba Kiraly wrote: >>> What Cenk is saying sounds a reasonable hack, but the standard = itself is in my opinion a bit underspecified for the semantics of = DAO-ACK messages in several ways. >>=20 >> A document which updated RFC6550 would be welcome here. >=20 > I could extend my previous summary into a more proper document, but I = have no experience with RFC writing, so I would prefer to team up with = someone who is more knowledgeable in the writing style. Anyone willing = to help? >=20 > Csaba >=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Oct 15 23:52:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8261B2F8D for ; Thu, 15 Oct 2015 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IiHUS_DWNaN for ; Thu, 15 Oct 2015 23:52:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEE41B2F8A for ; Thu, 15 Oct 2015 23:52:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCP75492; Fri, 16 Oct 2015 06:52:17 +0000 (GMT) Received: from SZXEML433-HUB.china.huawei.com (10.82.67.210) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 07:52:14 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.53]) by szxeml433-hub.china.huawei.com ([10.82.67.210]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 14:50:53 +0800 From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Semantics of DAO ACK Thread-Index: AQHQ+u9ZrOL6bWvrvE6fSZTBFoYmXJ5TeemAgAB/gwCAALuCgIABxtQAgAAS9ACAARsrAIAAJWsAgAAFz4CAANpTAIAVEedw Date: Fri, 16 Oct 2015 06:50:53 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5C500798@szxeml558-mbs.china.huawei.com> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> <560EA05A.3080002@fbk.eu> <560F5C5E.8010806@fbk.eu> In-Reply-To: <560F5C5E.8010806@fbk.eu> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.215.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 06:52:45 -0000 V2UgaGF2ZSBhbHNvIGltcGxlbWVudGVkIHRoaXMgZW5kLXRvLWVuZCBBQ0sgZmVhdHVyZSBpbiBv dXIgc29sdXRpb24gaW4gSHVhd2VpLiBBbmQgdGhpcyBlbmQtdG8tZW5kIEFDSyBoYXMgYmVjb21l IGltcG9ydGFudCBlc3BlY2lhbGx5IGluIGNvbnRleHQgdG8gYmlnZ2VyIG5ldHdvcmtzLiBXaXRo b3V0IHRoaXMgZmVhdHVyZSBpdCBpcyBpbXBvc3NpYmxlIGZvciB0aGUgbm9kZSB0byBrbm93IHdo ZW4gdG8gaW5pdGlhdGUgdGhlIGFwcGxpY2F0aW9uIHRyYWZmaWMgKGVzcGVjaWFsbHkgYmlkaXJl Y3Rpb25hbCB0cmFmZmljLCBsaWtlIEpvYWtpbSBtZW50aW9uZWQpLiBTZWNvbmRseSBpdCBhbHNv IHJlZHVjZXMgbmV0d29yayBjb252ZXJnZW5jZSB0aW1lIGZvciBiaWdnZXIgbmV0d29ya3MgKG9m LWNvdXJzZSBhdCB0aGUgY29zdCBvZiBhZGRpdGlvbmFsIEFDSyB0cmFmZmljKSwgYmVjYXVzZSB0 aGUgcmVwYWlycyBhcmUgdHJpZ2dlcmVkIHNvb24gd2hlbiB0aGUgQUNLcyBkbyBub3QgYXJyaXZl LiBXZSBoYWQgZm91bmQgZ29vZCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMgZm9yIDFLIG5vZGUg bmV0d29yayAod2l0aCByb3VnaGx5IDE2IGhvcHMpIGFuZCBpdCBjZXJ0YWlubHkgaW1wcm92ZXMg dGhlIG5ldHdvcmsgY29udmVyZ2VuY2UgdGltZSBhbmQgdGhlIG5vZGVzIGhhdmUgIG1vcmUgZGV0 ZXJtaW5pc3RpYyB3YXkgb2Yga25vd2luZyB3aGVuIHRvIGluaXRpYXRlIHRoZSB0cmFmZmljLg0K DQpJTU8sIHRoaXMgZXh0ZW5zaW9uIHdpbGwgaGVscCBpbiBhIGJpZyB3YXkuDQoNClRoZXJlIGFy ZSBmZXcgbW9yZSBwb2ludHM6DQoxLiBDYW4gdGhlIEUyRS1BQ0sgc2VudCBieSB0aGUgZ3JvdW5k ZWQgcm9vdCBiZSBhZ2dyZWdhdGVkID8gVGhpcyBpcyBwb3NzaWJsZSB3aXRoIHRoZSBFMkUtQUNL IGdvaW5nIG9uZSBob3AuDQoyLiBTb21lIGd1aWRlbGluZXMgb24gd2hhdCB0aW1lcnMgdGhlIGVu ZCBub2RlcyBzaG91bGQgdXNlIGZvciBEQU8gcmV0cnkgaW4gY2FzZSB0aGUgRTJFLUFDSyBpcyBu b3QgcmVjZWl2ZWQuIFRoZSB0aW1lcnMgbmVlZCB0byBiZSBzZXQgdG8gYSBjb25zZXJ2YXRpdmUg KGhpZ2hlcikgdmFsdWUgb3RoZXJ3aXNlIHRoZSBjdW11bGF0aXZlIERBTyByZXRyaWVzIHdpbGwg bmVnYXRpdmVseSBpbXBhY3QgdGhlIG5ldHdvcmsuDQoNClJlZ2FyZHMsDQpSYWh1bA0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3NhYmEgS2lyYWx5DQpTZW50OiAwMyBPY3RvYmVyIDIw MTUgQU0gMTA6MTENClRvOiByb2xsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1JvbGxdIFNlbWFu dGljcyBvZiBEQU8gQUNLDQoNClNpbmNlIHdlIHdlcmUganVtcGluZyB0aHJvdWdoIHNldmVyYWwg dG9waWNzIGFyb3VuZCB0aGUgREFPLUFDSyBzZW1hbnRpY3MgaW4gdGhpcyB0aHJlYWQsIEkgd3Jv dGUgYSBxdWljayBtZW1vIG9mIHdoYXQgaGFkIGJlZW4gYnJvdWdodCB1cCB0aWxsIG5vdy4gSSB0 aG91Z2h0IGl0IG1pZ2h0IHdvcnRoIHNoYXJpbmc6DQoNCkRBTy1BQ0sgc2VtYW50aWNzDQotLS0t LS0tLS0tLS0tLS0tLQ0KDQoxLCBBQ0sgZm9yIERBTyB3aXRoIG11bHRpcGxlIFQrVCBbSm9ha2lt XQ0KICAtIHN0YXR1cyBjb2RlIDEtMTI3LCBhbmQgY29weSByZWplY3RlZCBUYXJnZXQgW0Nlbmtd DQogIC0gbmV3IG9wdGlvbiB3aXRoIGluZGl2aWR1YWwgc3RhdHVzIGNvZGVzIChzYW1lIHNlbWFu dGljcyBhcyB3aXRoIG11bHRpcGxlIGluZGl2aWR1YWwgbWVzc2FnZXMpIFtDc2FiYV0NCiAgICAt IHNlbmQgaW5kaXZpZHVhbCBBQ0tzIGZvciBlYWNoIFRhcmdldCBbSm9ha2ltXQ0KICAgICAgLSBt ZW1vcnkgY29uY2VybnMsIGJldHRlciB0byBpbmNsdWRlIFRhcmdldCBpbiByZXNwb25zZSBbSm9h a2ltXQ0KICAgICAgICAtIOKAnEbigJ0gZmxhZyBpbiBEQU8gdG8gcmVxdWVzdCBmdWxsIEFDSyB3 aXRoIFQrVCBvciBwYXJ0aWFsIEFDSyB3aXRoIHN0YXR1cyBjb2RlcyBvbmx5IFtDc2FiYV0NCiAg LSBtZWFuaW5nIG9mIHN0YXR1cyBjb2RlIFtQYXNjYWxdDQogICAgLSBlbnVtZXJhdGlvbg0KICAg ICAgLSBib3RoIEpvYWtpbSBhbmQgd2UgdXNlIHRoaXMgKG5vdCBmb3IgbXVsdGlwbGUgVCtULCBi dXQgdG8gZGlmZmVyZW50aWF0ZSBkaWZmZXJlbnQgcmVhc29ucyBvZiBEQU8gcmVqZWN0aW9uKQ0K ICAgICAgLSB3b3VsZCBuZWVkIHJlZ2lzdHJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5IFtQYXNjYWxd DQogICAgLSBtZXRyaWM6IGFzIOKAnHNjYWxhciBkZWdyZWUgb2YgdW53aWxsaW5nbmVzc+KAnSBj YWxjdWxhdGVkIGJhc2VkIG9uIGF2YWlsYWJsZSByZXNvdXJjZXMgW1Bhc2NhbF0NCiAgICAgIC0g Y291bGQgYmUgZGlmZmljdWx0IHRvIGNvbWJpbmUgaXQgaW50byBvbmUgc2NhbGFyIGRlZ3JlZSBp biBvbmUgYnl0ZSBbSm9ha2ltLCBDc2FiYV0NCiAgICAgIC0gbWlnaHQgYmUgYmV0dGVyIHRvIHB1 dCB0aGUgcmVzb3VyY2UgaW5mbyBpbiBESU8gb3IgaW4gYSBEQU8gb3B0aW9uIFtDc2FiYV0NCiAg LSBBQ0sgd2l0aCByZWplY3RlZCBUK1QgYW5kIHN0YXR1cyBjb2RlIGZvciBlYWNoOyByZWxhdGlv biB0byBwYXRoIGNvbnRyb2wgW1Bhc2NhbF0NCiAgLSDigJxBbGwtb3Itbm90aGluZ+KAnSBmbGFn IGluIERBTyBbSm9ha2ltXQ0KDQoyLCBBQ0sgc2VtYW50aWNzOiBvbmUtaG9wIHZzLiBlbmQtdG8t ZW5kIGNvbnRleHQgW0NzYWJhXQ0KICAtIHdoZW4gc3BlYWtpbmcgb2YgZW5kLXRvLWVuZCBjb250 ZXh0LCB3ZSBkbyBub3QgcmVmZXIgdG8gYSBEQU8gYWRkcmVzc2VkIGRpcmVjdGx5IHRvIHRoZSBy b290LCBsaWtlIGluIG5vbi1zdG9yaW5nLCBidXQgdG8gYSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRp b24gb2YgdGhlIEFDSyBvZiB0aGUgb25lLWhvcCBEQU8gW0NzYWJhLCBKb2FraW1dDQogIC0gdXNl ZCBpbiBZYW56aSBbSm9ha2ltXQ0KICAtIGRyYWZ0ZWQgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50 YWdlcyBbUGFzY2FsLCBDc2FiYSwgSm9ha2ltXQ0KICAgIC0gcG9zc2libGUgZGVhZGxvY2sgW1Bh c2NhbF0NCiAgICAtIGlzIGl0IFJGQzY1NTA/DQogICAgLSBvbmUtaG9wIEFDSyBpcyBub3QgZW5v dWdoIGluZm8sIG5lZWRzIGVuZC10by1lbmQgZm9yIGRlY2lzaW9uIGxvZ2ljIFtDc2FiYSwgSm9h a2ltXQ0KDQozLCBmaXggbWVhbmluZyBvZiBzdGF0dXMgY29kZSAxMjcgKGp1c3QgYSB0eXBvIGlu IHRoZSBSRkMpIFtDc2FiYV0NCg0KNCwgc3RhdHVzIGNvZGUgaW4gQUNLIGZvciBOby1wYXRoIERB TyBub3QgZGVmaW5lZCBjbGVhcmx5IFtDc2FiYV0NCiAgLSBvbmx5IGNvZGUgMCBtYWtlcyBzZW5z ZSBbSm9ha2ltXQ0KICAtIG5vdCB1c2luZyBlbmQtdG8tZW5kIGNvbnRleHQgaW4gdGhpcyBjYXNl IFtKb2FraW1dDQoNCjUsIG11bHRpcGxlIERBTyBBQ0tzIGZvciBzYW1lIERBTyBbSm9ha2ltLCBD c2FiYV0NCiAgLSB0byBoYW5kbGUgbXVsdGlwbGUgVCtUIFtKb2FraW1dDQogIC0gdG8gaGF2ZSBi b3RoIGVuZC10by1lbmQgYW5kIG9uZS1ob3AgQUNLIHNlbWFudGljcyBbQ3NhYmFdDQoNCkRpc2Ns YWltZXI6IHRoaXMgZG9lc24ndCB3YW50IHRvIGJlIGEgZnVsbCBzdW1tYXJ5LCBhbmQgSSBvYnZp b3VzbHkgc2tpcHBlZCBtYW55IGRldGFpbCBpbiBzdWNoIGEgYnJpZWYgd3JpdGV1cC4NCg0KQ2hl ZXJzLA0KQ3NhYmENCg0KT24gMDIvMTAvMTUgMTc6MzksIEpvYWtpbSBFcmlrc3NvbiB3cm90ZToN Cj4gIEZyb20gbXkgcGVyc3BlY3RpdmUgd2UgcmVhbGx5IG5lZWQgdGhlIGVuZC10by1lbmQgQUNL IHRoYXQgaXMgbmVlZGVkIA0KPiAtIHRoZSBzaW5nbGUgaG9wIEFDSyBpcyBvZiBubyB1c2UgYXQg YWxsIGlmIHlvdSBhaW0gYXQgYnVpbGRpbmcgc2NhbGFibGUgUlBMIG5ldHdvcmtzIHRoYXQgaGF2 ZSBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uLg0KPg0KPiBXZSBoYXZlIHdvcmtlZCB3aXRo IHRoaXMgZm9yIHF1aXRlIGEgd2hpbGUgYXQgWWFuemkgTmV0d29ya3MgYW5kIEkgDQo+IHdvdWxk IHNheSB0aGF0IGlmIHdlIGdldCBhIGRlYWRsb2NrIHNvbWV3aGVyZSB0aGF0IGlzIHByb2JhYmx5 IGFuIA0KPiBpbmRpY2F0aW9uIHRoYXQgdGhlIHNlbGVjdGVkIHBhdGgvcGFyZW50IHdhcyBhIGJh ZCBvbmUgYW5kIHRoYXQgdGhlIA0KPiBub2RlIHNob3VsZCBsb29rIGZvciBhbHRlcm5hdGl2ZXMu IElmIHdlIGluc3RlYWQgd291bGQgaGF2ZSBnb3R0ZW4gYSANCj4gREFPIEFDSyBvdmVyIHNpbmds ZS1ob3AgdGhlIG5vZGUgd291bGQgYXNzdW1lIGNvbm5lY3Rpdml0eSAtIGJ1dCBiZSANCj4gd3Jv bmcgYW5kIHNvbWUgb3RoZXIgbWVjaGFuaXNtICh1c3VhbGx5IHRoZSBhcHBsaWNhdGlvbikgbmVl ZHMgdG8ga2ljayANCj4gaW4gYW5kIHRyaWdnZXIgcmVwYWlycy4gVGhpcyBpcyBmb3IgbWUgbm90 IHRoZSB3YW50ZWQgYmVoYXZpb3VyIGFuZCBJIA0KPiByYXRoZXIgdGFrZSB0aGUgcmlzayBvZiBv bmUgb3IgYSBmZXcNCj4gKHNob3J0LXRlcm0pIGRlYWQtbG9ja3MgaWYgYSBub2RlIGluIHRoZSBw YXRoIHRvd2FyZHMgcm9vdCByZWJvb3RzIG9yIGluIG90aGVyIHdheXMgaXMgZ29uZS4NCj4NCj4g T2YgY291cnNlIGNvbWJpbmluZyBEQU8gQUNLIChlbmQtdG8tZW5kKSB3aXRoIGluZmluaXRlIGxp ZmV0aW1lIHJvdXRlcyANCj4gaXMgbm90IGFuIG9wdGltYWwgY29uZmlndXJhdGlvbiBpZiB0aGVy ZSBhcmUgbWFueSByZWJvb3RzIGFuZCANCj4gZGVhZC1sb2Nrcy4gVGhhdCBpcyB3aHkgd2UgdHJ5 IHRvIGtlZXAgcm91dGluZyBsaWZldGltZSByZWFzb25hYmx5IA0KPiBzaG9ydA0KPiAoMzAgbWlu dXRlcykgc28gdGhhdCBhbnkgcm91dGVzIHRoYXQgZW5kZWQgdXAgYmVpbmcg4oCcc3R1Y2vigJ0g c29tZXdoZXJlIA0KPiB3aWxsIGJlIGdhcmJhZ2UgY29sbGVjdGVkIGFmdGVyIGEgd2hpbGUuDQo+ DQo+IEJlc3QgcmVnYXJkcywNCj4g4oCUIEpvYWtpbSBFcmlrc3NvbiwgU0lDUw0KPg0KPg0KPj4g T24gMDIgT2N0IDIwMTUsIGF0IDE3OjE4LCBDc2FiYSBLaXJhbHkgPGtpcmFseUBmYmsuZXU+IHdy b3RlOg0KPj4NCj4+IEhpIFBhc2NhbCwNCj4+DQo+PiBUaGUgY29yZSBvYnNlcnZhdGlvbiBiZWhp bmQgdGhlIGVuZC10by1lbmQsIG9yIGRlbGF5ZWQgQUNLIChhdCBsZWFzdCBvbiBteSBzaWRlLCBJ IGRvbid0IGtub3cgZm9yIEpvYWtpbSkgaXMgdGhhdCB3aGlsZSB0aGUgb25lLWhvcCBOQUNLIGNv bnRhaW5zIGltcG9ydGFudCBpbmZvcm1hdGlvbiwgdGhlIG9uZS1ob3AgQUNLIGlzIG5vdCByZWFs bHkgd2hhdCB5b3UgYXJlIGludGVyZXN0ZWQgaW4uIEluIGZhY3QsIGltcGxlbWVudGF0aW9ucyBJ J3ZlIGNoZWNrZWQgZWl0aGVyIGRvbid0IGV2ZW4gYXNrIGZvciBpdCwgb3IgaWYgdGhleSBkbywg dGhleSBzdGlsbCBkb24ndCBkbyBhbnl0aGluZyBvbiBhIHBvc2l0aXZlIEFDSy4gSWYgaW5zdGVh ZCB5b3UgZGVsYXkgQUNLcywgb3IgaW4gb3RoZXIgd29yZHMgd2FpdCBmb3IgYWxsIHRoZSBwYXJl bnRzIHRvIEFDSywgdGhpcyBBQ0sgb3IgTkFDSyBicmluZ3MgaW4gYW4gaW1wb3J0YW50IHBpZWNl IG9mIGluZm9ybWF0aW9uLg0KPj4NCj4+IE5vdGljZSB0aGF0IGlmIHlvdXIgaW1tZWRpYXRlIHBh cmVudCB3b3VsZCBOQUNLLCBpdCB3b3VsZCBOQUNLIGltbWVkaWF0ZWx5IGluIGJvdGggaW50ZXJw cmV0YXRpb25zLiBGZWVkYmFjayBvbmx5IGNoYW5nZXMgd2hlcmUgdGhpbmdzIGdvIHdlbGwsIG9y IHRoaW5ncyBnbyB3ZWxsIHRpbGwgc29tZSBwb2ludCBvbiB0aGUgcmVjdXJzaXZlIHBhdGgsIGJ1 dCBmYWlsIGFmdGVyLiBJbiB0aGUgZmlyc3QsIHlvdSBnZXQgYW4gQUNLIGFuZCB5b3Uga25vdyB5 b3UgYXJlIHJlYWNoYWJsZS4gSW4gdGhlIGxhdHRlciwgeW91IGRvIGdldCB0byBrbm93IHRoZSBw cm9ibGVtIGFuZCB5b3UgY2FuIGFjdCB1cG9uLiBDb252ZXJnZW5jZSBpcyBzdXJlbHkgc29tZXRo aW5nIHRoYXQgbmVlZHMgdG8gYmUgc3R1ZGllZCBjYXJlZnVsbHksIGJ1dCBJIHRoaW5rIGRlbGF5 ZWQgQUNLIHdpbGwgbm90IGNyZWF0ZSBtb3JlIGlzc3VlcyB0aGFuIHdoYXQgeW91IGFscmVhZHkg aGF2ZSB3aXRoIHRoZSBvbmUtaG9wIEFDSy4NCj4+DQo+PiBUaGUgcG9pbnQgdGhhdCBJIHRyaWVk IHRvIHJhaXNlIHdoZW4gSSBicm91Z2h0IHRoaXMgdXAsIGJ1dCBtYXliZSBpdCB3YXNuJ3QgY2xl YXIsIGlzIHRoYXQgSSB0aGluayBib3RoIGFyZSBjb25mb3JtYW50IHRvIFJGQzY1NTAuIFdoaWNo LCBpZiBJJ20gY29ycmVjdCwgYnJpbmdzIG1lIHRvIHRoZSBwb2ludCB0aGF0IGNsYXJpZmljYXRp b25zIG1pZ2h0IGJlIG5lZWRlZCBhYm91dCBBQ0tzIGluIGFuIFJGQyB0byBhdm9pZCBpbnRlcm9w ZXJhYmlsaXR5IHByb2JsZW1zLCBhbmQgSSB0aGluayBpdCBpcyBuZWVkZWQgaW5kZXBlbmRlbnQg b2Ygd2hldGhlciB0aGUgZW5kLXRvLWVuZCBjb250ZXh0IGlzIGEgZ29vZCBpZGVhIG9yIG5vdC4g WW91IGNvdWxkIGV2ZW4gdGhpbmsgb2Ygc2VuZGluZyBib3RoIHR5cGVzIG9mIEFDS3MsIGJ1dCB0 aGF0IHdvdWxkIGJyaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiBvdXQgb2YgUkZDNjU1MC4NCj4+DQo+ PiBDaGVlcnMsDQo+PiBDc2FiYQ0KPj4NCj4+IE9uIDAyLzEwLzE1IDE1OjA0LCBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPj4+IEhlbGxvIEpvYWtpbToNCj4+Pg0KPj4+IFdoYXQg SSByZWFkIGhlcmUgYm9pbHMgZG93biB0byBhIGxpbWl0ZWQgZGlmZnVzaW9uIGFsZ29yaXRobS4g V2UgdHJpZWQgdG8gYXZvaWQgdGhhdCBpbiBSUEwgYmVjYXVzZSBhbnkgbW92ZW1lbnQgd2l0aGlu IHRoZSBjb252ZXJnZW5jZSB3b3VsZCBjYXVzZSBhIGRlYWRsb2NrLiBJT1cgaWYgZXZlcnkgbm9k ZSB3YWl0cyBmb3IgKGFsbCBvZikgdGhlIHBhcmVudHMgdG8gYWNrLCB0aGVuIHRoaXMgcmVjdXJz aXZlbHkgdGFrZXMgeW91IHRvIHRoZSByb290LCBhbmQgaWYgYW55IG5vZGUgaW4gdGhlIGNoYWlu IG1vdmVzIG9yIGRpZXMsIHRoZSBkaWZmdXNpb24gd2lsbCBub3QgYmUgY29tcGxldGUuDQo+Pj4N Cj4+PiBDaGVlcnMsDQo+Pj4NCj4+PiBQYXNjYWwNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9ha2ltIA0KPj4+PiBFcmlrc3Nvbg0KPj4+PiBTZW50OiBqZXVkaSAx IG9jdG9icmUgMjAxNSAyMjoxMQ0KPj4+PiBUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBbUm9sbF0g U2VtYW50aWNzIG9mIERBTyBBQ0sNCj4+Pj4NCj4+Pj4NCj4+Pj4+IE9uIDAxIE9jdCAyMDE1LCBh dCAyMTowMywgQ3NhYmEgS2lyYWx5IDxraXJhbHlAZmJrLmV1PiB3cm90ZToNCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IE9uIDMwLzA5LzE1IDE3OjU1LCBKb2FraW0gRXJpa3Nzb24gd3JvdGU6 DQo+Pj4+Pj4+IE9uIDMwIFNlcCAyMDE1LCBhdCAwNjo0NCwgQ3NhYmEgS2lyYWx5IDxraXJhbHlA ZmJrLmV1PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSGVsbG8gSm9ha2ltLA0KPj4+Pj4+Pg0K Pj4+Pj4+PiBJIGhhdmUgYWxzbyB3b3JrZWQgb24gdGhlIENvbnRpa2kgREFPLUFDSyBjb2RlLCBl bmFibGluZyBBQ0tzLA0KPj4+PiBpbXBsZW1lbnRpbmcgZml4ZXMgdG8gdGhlIERBT1NlcXVlbmNl IGhhbmRsaW5nLCBhbmQgbG9va2luZyBpbnRvIA0KPj4+PiBtdWx0aXBsZSB0YXJnZXRzLg0KPj4+ Pj4+IE5pY2UsIEkgaGF2ZSBhIFBSIG9uIENvbnRpa2kgbm93IHdpdGggd2hhdCB3ZSBoYXZlIGJl ZW4gZG9pbmcgdG8gDQo+Pj4+Pj4gZ2V0DQo+Pj4+IENvbnRpa2kgUlBMIG1vcmUgc2NhbGFibGUg KGJ1dCBzdGlsbCBvbmx5IHNpbmdsZSB0YXJnZXRzIC8gcGF0aHMpLg0KPj4+Pj4+PiBXaGF0IENl bmsgaXMgc2F5aW5nIHNvdW5kcyBhIHJlYXNvbmFibGUgaGFjaywgYnV0IHRoZSBzdGFuZGFyZCAN Cj4+Pj4+Pj4gaXRzZWxmDQo+Pj4+IGlzIGluIG15IG9waW5pb24gYSBiaXQgdW5kZXJzcGVjaWZp ZWQgZm9yIHRoZSBzZW1hbnRpY3Mgb2YgREFPLUFDSyANCj4+Pj4gbWVzc2FnZXMgaW4gc2V2ZXJh bCB3YXlzLg0KPj4+Pj4+IFllcywgaXQgaXMgdW5kZXJzcGVjaWZpZWQuIFRoZXJlIGlzIG5lZWQg Zm9yIGNsYXJpZmljYXRpb25zIGFuZCANCj4+Pj4+PiBtb3JlIGRldGFpbHMNCj4+Pj4gb24gdGhl IERBTyAvIERBTyBBQ0shDQo+Pj4+Pj4+IE15IHByZWZlcnJlZCBzb2x1dGlvbiBmb3IgQUNLaW5n IERBTyBtZXNzYWdlcyB3aXRoIG11bHRpcGxlIA0KPj4+Pj4+PiB0YXJnZXRzDQo+Pj4+IHdvdWxk IGJlIHRvIGhhdmUgc3VwcG9ydCBmb3IgdGhlIHNhbWUgc2VtYW50aWNzIHRoYXQgeW91IHdvdWxk IGhhdmUgDQo+Pj4+IGhhZCB3aXRoIG9uZSBEQU8gbWVzc2FnZSBwZXIgVGFyZ2V0LCBpLmUuLCBJ IHdvdWxkIHByZWZlciBhbiBvcHRpb24gDQo+Pj4+IGZpZWxkIHRoYXQgZ2l2ZXMgYW4gaW5kaXZp ZHVhbCBzdGF0dXMgZm9yIGVhY2ggVGFyZ2V0Lg0KPj4+Pj4+IFllcywgYnV0IHRoYXQgd291bGQg cmVxdWlyZSBtb3JlIG1lbW9yeSBpbiB0aGUgc2VuZGluZyBub2RlIHRvIA0KPj4+Pj4+IGtlZXAN Cj4+Pj4gdHJhY2sgb2YgdGhpbmdzIG9yIGZ1bGwgc3BlY2lmaWNhdGlvbiBvZiB0aGUgdGFyZ2V0 IGluIHRoZSByZXNwb25zZS4NCj4+Pj4+PiBJIGd1ZXNzIGl0IG1pZ2h0IGJlIHNvbHZlZCBieSBh bGxvd2luZyBtdWx0aXBsZSBEQU8gQUNLcyBmb3IgdGhlIA0KPj4+Pj4+IHNhbWUNCj4+Pj4gREFP IGFuZCB0byBoYXZlIHRoZSBUYXJnZXQgb3B0aW9ucyBpbmNsdWRlZCBpbiB0aGUgREFPIEFDSy4N Cj4+Pj4+IFRoaXMgaXMgYSBjb21wcm9taXNlIHRvIGNvbnNpZGVyIGZvciBzdXJlLiBJZiB5b3Ug bG9vayBhdCBteQ0KPj4+PiBpbXBsZW1lbnRhdGlvbiwgeW91IGNhbiBzZWUgdGhhdCBJIHVzZSB0 aGUgcm91dGluZyB0YWJsZSBlbnRyeSB0byANCj4+Pj4gbWF0Y2ggdGhlIERBTyBBQ0ssIGFuZCBJ IGtlZXAgb25seSBEQU9TZXF1ZW5jZSAoU0VRKSBhcyBleHRyYSANCj4+Pj4gc3RhdGUuIEknbSBu b3Qgc3VyZSBpdCB3b3VsZCB3b3JrIGluIGFsbCBjYXNlcywgYnV0IGl0IGRpZCB3b3JrIGZvciAN Cj4+Pj4gdGhlIGNhc2UgSSBjb25zaWRlcmVkLiBJJ20ga2VlcGluZyBvbmx5IHRoZSBTRVEsIGFu ZCBJIHRoaW5rIHRoaXMgDQo+Pj4+IGlzIGEgbXVzdCBpZiB5b3UgaGF2ZSBubyBhZ2dyZWdhdGlv biwgYW5kIHlvdSB3YW50IHRvIG1hdGNoIGluIGNhc2UgDQo+Pj4+IHlvdSBmb3J3YXJkIG11bHRp cGxlIERBT3MgYmVmb3JlIGdldHRpbmcgdGhlIEFDSyBvciB0aW1pbmcgb3V0IG9uIA0KPj4+PiBp dC4gSW4gZmFjdCwgc2ltcGx5IGVuYWJsaW5nIEFDS3MgaW4gdGhlIG9yaWdpbmFsIGNvZGUgd2Fz IG1lc3NpbmcgDQo+Pj4+IHVwIHRoZSBtYXRjaCBiZXR3ZWVuIERBT3MgYW5kIHRoZWlyIEFDS3Mg YmVjYXVzZSBpdCB3YXNuJ3QgZXZlbiBrZWVwaW5nIHRyYWNrIG9mIHRoZSBEQU8gc2VxdWVuY2Ug bnVtYmVycy4NCj4+Pj4+IElmIHlvdSBkbyBhZ2dyZWdhdGUgQUNLcywgb3IgeW91IGhhdmUgbW9y ZSBjb21wbGV4IFRhcmdldCtUcmFuc2l0DQo+Pj4+IHNjZW5hcmlvcywgdGhlIGdhbWUgY2hhbmdl cywgYW5kIEkgZG9uJ3Qga25vdyB3aGF0IHdvdWxkIGJlIHRoZSANCj4+Pj4gYmFsYW5jZSBiZXR3 ZWVuIHN0YXRlIHlvdSBoYXZlIHRvIGtlZXAgYW55d2F5IGFuZCBzdGF0ZSB5b3Uga2VlcCANCj4+ Pj4ganVzdCB0byBiZSBhYmxlIHRvIGludGVycHJldCBhIGxhdGVyIEFDSyBjb3JyZWN0bHkuIEkg dGhpbmsgaXQgaXMgDQo+Pj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCBzbyBteSBzdWdnZXN0 aW9uIHdvdWxkIGJlIGEgZmxhZyB0byANCj4+Pj4gaW5kaWNhdGUgd2hldGhlciB5b3UgcmVxdWVz dCBmdWxsIEFDSyAoYnVtcGluZyBiYWNrIGFsbCBUK1QgaW5mbyANCj4+Pj4gZm9yIHJlamVjdGVk IGVudHJpZXMgaW4gdGhlIERBTykgb3IgYSBtdWNoIHNtYWxsZXIgcGFydGlhbCBBQ0sgd2l0aCAN Cj4+Pj4gU0VRIGFuZCBzaW1pbGFyIElEcyBvbmx5LiBUaGlzIGZsYWcgKGxldHMgY2FsbCBpdCBG IGZvciBub3cpLCBjb3VsZCANCj4+Pj4gZ28gcmlnaHQgbmV4dCB0byBLLiBBcyB0aGUgREFPIHBy b3BhZ2F0ZXMsIGVhY2ggbm9kZSBjb3VsZCBzZXQgRiANCj4+Pj4gYmFzZWQgb24gd2hldGhlciBp dCBpcyBhYmxlIHRvIHN0b3JlIGFuZC9vciByZXByb2R1Y2UgaW5mbyAoRiBub3QgDQo+Pj4+IHNl dCkgb3IgY2hvc2UgdG8gcmVtYWluIHN0YXRlbGVzcyAoc2V0IEYgKS4gVGhpcyB3b3VsZCBleGNs dWRlIGFnZ3JlZ2F0aW9uIGluIHRoZSBEQU8tQUNLIHNlbnQgZG93biwgYnV0IHN0aWxsIGFsbG93 IGZvciBhZ2dyZWdhdGlvbiBpbiB0aGUgREFPIHNlbnQgdXAuDQo+Pj4+Pj4+IFRvIGdpdmUgYW5v dGhlciBleGFtcGxlIG9mIHN1YnRsZSBwcm9ibGVtcyB3aXRoIERBTy1BQ0ssIGl0IHdhcyANCj4+ Pj4+Pj4gbm90DQo+Pj4+IGNsZWFyIHRvIG1lIHdoZXRoZXIgSSB3YW50IG15IGltcGxlbWVudGF0 aW9uIHRvIEFDSyB3aGVuIHRoZSBUYXJnZXQgDQo+Pj4+IGlzIGFkZGVkIHRvIHRoZSByb3V0aW5n IHRhYmxlLCBvciBvbmx5IHdoZW4gdGhpcyBub2RlIGl0c2VsZiANCj4+Pj4gcmVjZWl2ZXMgYW4g QUNLIGZvciB0aGUgc2FtZSBUYXJnZXQgZnJvbSBpdHMgcGFyZW50LiBCb3RoIG1ha2VzIA0KPj4+ PiBzZW5zZSwgd2l0aCB0aGUgZm9ybWVyIGdpdmluZyBhIHF1aWNrIG9uZS1ob3AgQUNLLCB3aGls ZSB0aGUgbGF0dGVyIA0KPj4+PiB3b3JrcyBhcyBhbiBlbmQtdG8tZW5kIEFDSywgZW5zdXJpbmcg dGhhdCB0aGUgcGF0aCBpcyBhY3R1YWxseSANCj4+Pj4gYnVpbHQuIEJvdGggbG9vayBjb25mb3Jt YW50IHRvIHRoZSBzdGFuZGFyZCwgYnV0IEkgc3VwcG9zZSB0aGUgDQo+Pj4+IG9yaWdpbmFsIGF1 dGhvciB3YXMgdGhpbmtpbmcgb2YgdGhlIGZvcm1lciwgYW5kIEkgY2FuIGVhc2lseSBzZWUgDQo+ Pj4+IGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgYXJpc2luZyBiZXR3ZWVuIHR3byBpbXBsZW1l bnRhdGlvbnMgdXNpbmcgZGlmZmVyZW50IHNlbWFudGljcy4NCj4+Pj4+PiBXZSBkaWQgZ28gZm9y IHRoZSBlbmQtdG8tZW5kIEFDSyB0byBhY2hpZXZlIGJldHRlciBzY2FsYWJpbGl0eS4gDQo+Pj4+ Pj4gVGhlcmUgaXMgdG8gbWUgbm8gcG9pbnQgaGF2aW5nIGEgcm91dGUgdG8gdGhlIHBhcmVudCBp ZiBpdCBpcyBub3QgDQo+Pj4+Pj4gcG9zc2libGUgdG8gZ2V0DQo+Pj4+IGl0IGFsbCB0aGUgd2F5 IHRvIHJvb3QuIEJ1dCBJIHRvdGFsbHkgYWdyZWUgLSB0aGlzIGlzIG5vdCBvYnZpb3VzIA0KPj4+ PiBmcm9tIHRoZSBSUEwgUkZDIGVpdGhlci4NCj4+Pj4+IERvIHlvdSBtZWFuIGVuZC10by1lbmQg QUNLIGFzIGluIG5vbi1zdG9yaW5nLCBvciBlbmQtdG8tZW5kIEFDSyBpbiANCj4+Pj4+IHRoZQ0K Pj4+PiBzZW5zZSB0aGF0IGl0IGlzIHN0aWxsIGFkZHJlc3NlZCB0byB0aGUgbmV4dCBob3AgYnV0 IHlvdSBkZWxheSBBQ0sgDQo+Pj4+IHRpbGwgeW91IGtub3cgeW91ciBwYXJlbnQgKGFuZCBhbGwg aXRzIHBhcmVudHMpIEFDS2VkPw0KPj4+PiBJIG1lYW4gZW5kLXRvLWVuZCBhcyBpbiB3YWl0aW5n IGZvciBhbGwgdGhlIHBhcmVudHMgdG8gQUNLIHNvIHRoYXQgDQo+Pj4+IGJlZm9yZSBBQ0tpbmcg aXQgaXMga25vd24gdGhhdCB0aGUgcm91dGUgaXMgcHJvcGVybHkgaW5zdGFsbGVkIHdoZXJlIGl0 IG5lZWRzIHRvLg0KPj4+Pg0KPj4+Pj4+IERvIHlvdSBoYXZlIHlvdXIgQ29udGlraSBjb2RlIHNv bWV3aGVyZSBpbiB0aGUgb3Blbi1zb3VyY2U/DQo+Pj4+PiBJIGRpZCBzb21lIGNsZWFudXAgYW5k IHB1c2hlZCB0aGUgY2xlYW4gcGFydCBvZiB0aGUgY29kZSB0byBnaXRodWI6DQo+Pj4+PiBodHRw czovL2dpdGh1Yi5jb20vY3NraXJhbHkvY29udGlraS90cmVlL0RBTy1OQUNLDQo+Pj4+PiBJdCBp cyBub3QgeWV0IHJlYmFzZWQgdG8gdGhlIGxhdGVzdCBtYXN0ZXIsIGJ1dCBpdCBzaG91bGQgYXBw bHkuIEkgDQo+Pj4+PiBzdXBwb3NlDQo+Pj4+IGRlc2NyaWJpbmcgaXQgd291bGQgYmUgdG9vIG9m Zi10b3BpYyBmb3IgdGhlIGxpc3QuDQo+Pj4+PiBUaGVyZSBpcyBhbHNvIHRoZSBtb3JlIGV4cGVy aW1lbnRhbCBwYXJ0IG9mIHRoZSBjb2RlIGluIGEgUFIsIGlmIGludGVyZXN0ZWQuDQo+Pj4+IE9r IC0gSeKAmWxsIHRha2UgYSBsb29rIQ0KPj4+Pg0KPj4+PiBCVFc6IFdlIGhhdmUgZG9uZSBhIGZl dyBkZXBsb3ltZW50cyB1c2luZyBvdXIgaW1wbGVtZW50YXRpb24gdXNpbmcgDQo+Pj4+IFlhbnpp IG5ldHdvcmtzIHByb2R1Y3RzIC0gdGFrZSBhIGxvb2sgYXQgdGhpcyB2aWRlbyB3aGVyZSAxMDAw IA0KPj4+PiBub2RlcyBpcyBkZXBsb3llZCB3aXRoIENvbnRpa2kgUlBMICsgb3VyIGZpeGVzIGFu ZCAyMCBuZWlnaGJvcnMgYW5kIA0KPj4+PiByb3V0ZXMgcGVyIG5vZGUuIElmIHdpdGhvdXQgb3Vy IGZpeGVzIGl0IHdvdWxkIG5vdCB3b3JrIHNpbmNlIA0KPj4+PiBDb250aWtpIFJQTCBkaWQgbm90 IGFsbG93IHNjYWxpbmcgYmV5b25kIG51bWJlciBvZiBuZWlnaGJvcnMgYW5kIA0KPj4+PiByb3V0 ZXMgLyBub2RlIHRoYXQgd2VsbCBiZWZvcmUgdGhlc2UgZml4ZXMuDQo+Pj4+DQo+Pj4+IGh0dHA6 Ly93d3cueWFuemkuc2UvdmlkZW8uanNwP2lkPTcNCj4+Pj4NCj4+Pj4gQmVzdCByZWdhcmRzLA0K Pj4+PiDigJQgSm9ha2ltIEVyaWtzc29uDQo+Pj4+DQo+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+ PiBDc2FiYQ0KPj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+PiDigJQgSm9ha2ltDQo+Pj4+Pj4N Cj4+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+Pj4+PiBDc2FiYQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBP biAyOS8wOS8xNSAyMzowOCwgQ2VuayBHw7xuZG9nYW4gd3JvdGU6DQo+Pj4+Pj4+PiBIZWxsbyBK b2FraW0sDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBxdWVzdGlv biBhbmQgSSBhbHNvIGNvdWxkbid0IGZpbmQgYW55IA0KPj4+Pj4+Pj4gYW5zd2VycyBpbg0KPj4+ PiBSRkMgNjU1MC4NCj4+Pj4+Pj4+IEhvd2V2ZXIsIG15IHRob3VnaHRzIG9uIHRoaXMgYXJlIGFz IGZvbGxvd3M6DQo+Pj4+Pj4+PiBTaW5jZSBhIHN1Yi1zZXQgb2YgdGhlIGFubm91bmNlZCBSUEwg dGFyZ2V0cyBjb3VsZCBoYXZlIGJlZW4gDQo+Pj4+Pj4+PiBhY2NlcHRlZCBiZWZvcmUgZmlsbGlu ZyB1cCB0aGUgcm91dGluZyB0YWJsZSAoZS5nLiksIEkgd291bGQgDQo+Pj4+Pj4+PiBjaG9vc2Ug YQ0KPj4+PiBzdGF0dXMgY29kZSBiZXR3ZWVuIDEgYW5kIDEyNy4NCj4+Pj4+Pj4+IEkgd291bGQg ZXhwZWN0IGEgbm9kZSB0byBjaG9vc2UgYW5vdGhlciBwYXJlbnQgaWYgYSBtb3JlIA0KPj4+Pj4+ Pj4gYWdncmVzc2l2ZQ0KPj4+PiBzdGF0dXMgY29kZSBpcyByZWNlaXZlZCAoWzEyOC0yNTVdKS4N Cj4+Pj4+Pj4+IEJ1dCBhIGZ1bGwgcm91dGluZyB0YWJsZSBjYW4gaGF2ZSBmcmVlIHNwYWNlIGFn YWluIHVudGlsIHRoZSANCj4+Pj4+Pj4+IG5leHQgb3IgYW55DQo+Pj4+IHN1YnNlcXVlbnQgREFP IGFycml2ZXMgLi4NCj4+Pj4+Pj4+IHRoZXJlZm9yZSBJIHByZWZlciBhICJtaWxkIHJlamVjdGlv biIgd2l0aCBhIHN0YXR1cyBjb2RlIG9mIFsxLTEyN10uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVG8g Z2l2ZSBzb21lIGZlZWRiYWNrIHRvIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBEQU8sIGl0IG1pZ2h0 IGJlIA0KPj4+Pj4+Pj4gc2Vuc2libGUgdG8gY29weSB0aGUgcmVqZWN0ZWQgUlBMIFRhcmdldCBv cHRpb25zIGZyb20gdGhlIA0KPj4+Pj4+Pj4gYWZmZWN0ZWQgREFPIHRvIHRoZSBEQU8tQUNLLCBz byB0aGF0IHRoZSBvcmlnaW5hdG9yIGlzIGZ1bGx5IA0KPj4+Pj4+Pj4gYXdhcmUgb2Ygd2hpY2gN Cj4+Pj4gVGFyZ2V0IHByZWZpeGVzIGdvdCByZWplY3RlZCAoYW5kIHdoaWNoIG9uZXMgZ290IGFj Y2VwdGVkLCBpbXBsaWNpdGx5KS4NCj4+Pj4+Pj4+IEkgd291bGQgY2hvb3NlIHRoaXMgbWV0aG9k LCBiZWNhdXNlIGl0IGRvZXNuJ3QgcmVxdWlyZSB0aGUgDQo+Pj4+Pj4+PiBvcmlnaW5hdG9yIG9m IHRoZSBEQU8gdG8gc2F2ZSBhbnkgZXh0cmEgc3RhdGUgYWJvdXQgdGhlIERBTyBhbmQgDQo+Pj4+ Pj4+PiBpdHMNCj4+Pj4gY29udGVudHMuDQo+Pj4+Pj4+PiBOb25ldGhlbGVzcywgZXZlcnl0aGlu ZyBJIHdyb3RlIGlzIG5vbmNvbmZvcm0gYW5kIEkgYW0gYWxzbyANCj4+Pj4+Pj4+IGludGVyZXN0 ZWQgaW4gdGhlIFJQTCBleHBlcnRzJyBvcGluaW9ucyBhbmQgc29sdXRpb25zLg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IEJlc3QsDQo+Pj4+Pj4+PiBDZW5rDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMjku MDkuMjAxNSAyMTo0NCwgSm9ha2ltIEVyaWtzc29uIHdyb3RlOg0KPj4+Pj4+Pj4+IEhlbGxvIEFs bCwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgaGF2ZSBzcGVuZCBxdWl0ZSBzb21lIHRpbWUgdG8g Z2V0IGEgbW9yZSBzdGFibGUgDQo+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb24gb2YgREFPIGhhbmRs aW5nIGZvciBDb250aWtpIFJQTCBhbmQgSSBhbSANCj4+Pj4+Pj4+PiBjdXJyZW50bHkgbG9va2lu ZyBpbnRvIERBTyBhZ2dyZWdhdGlvbi4gQnV0IEkgcmVhbGlzZWQgdGhhdCBpdCANCj4+Pj4+Pj4+ PiBpcyBmb3IgbWUgbm90IDEwMCUgY2xlYXIgd2hhdCBhIG5vZGUgdGhhdCByZWNlaXZlcyBhIERB TyB3aXRoIA0KPj4+Pj4+Pj4+IHNldmVyYWwgcHJlZml4ZXMgdG8gYmUgcmVnaXN0ZXJlZCBidXQg Y2FuIG9ubHkgYWNjZXB0IGEgDQo+Pj4+Pj4+Pj4gc3ViLXNldCBvZiB0aGVtLiBTaG91bGQgaXQg YmUgYQ0KPj4+PiBEQU9fTkFDSyBpbiB0aGlzIGNhc2Ugb3IgaXMgdGhlcmUgYW55IG90aGVyIHdh eSB0byBoYW5kbGUgdGhhdCBjYXNlPw0KPj4+Pj4+Pj4+IElmIGVhY2ggd291bGQgaGF2ZSBiZWVu IHNlbnQgc2VwYXJhdGVseSBpdCBpcyBvYnZpb3VzIHRoYXQgdGhlIA0KPj4+Pj4+Pj4+IHJlY2Vp dmluZyBub2RlIGNhbiBkbyBhIE5BQ0sgd2hlbiB0aGUgcm91dGluZyB0YWJsZSBpcyBmdWxsIA0K Pj4+Pj4+Pj4+IGFuZCB0aGVyZWZvcmUgaXQgaXMgcG9zc2libGUgdG8gZ2V0IGZpbmUtZ3JhaW5l ZCBhbnN3ZXJzLiBCdXQgDQo+Pj4+Pj4+Pj4gd2l0aA0KPj4+PiBhZ2dyZWdhdGlvbiBvZiBEQU9z IHRoaXMgaXMgbm90IHRoZSBjYXNlLg0KPj4+Pj4+Pj4+IEFueSBpZGVhcz8NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+Pj4+PiDigJQgSm9ha2ltIEVyaWtzc29uLCBT SUNTDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IFJvbGxAaWV0Zi5v cmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwN Cj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IFJvbGxAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBSb2xsIG1haWxpbmcg bGlzdA0KPj4+Pj4+IFJvbGxAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4+Pj4gUm9sbEBp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xs DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+IFJvbGxAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBSb2xsIG1haWxpbmcgbGlzdA0KPj4+ IFJvbGxAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+PiBSb2xsQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxp c3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JvbGwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Fri Oct 16 01:28:22 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BB21B308D for ; Fri, 16 Oct 2015 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHaA9t2jMRZK for ; Fri, 16 Oct 2015 01:28:16 -0700 (PDT) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070041B3090 for ; Fri, 16 Oct 2015 01:28:15 -0700 (PDT) Received: by lffy185 with SMTP id y185so75307371lff.2 for ; Fri, 16 Oct 2015 01:28:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JhrVuKwaDypYmJyxBkbDb2Fo3fBJqip6euVgtG4wPm0=; b=ETMw3xL/UyciKHlJuap6DEsCOuNQpdWqYhGytfpA5Pwy/OuAeioOKzLcMZrXfOaVHs SpX8SkQNkKBICdGRn4+P8i8D062aaQoUim3QwlpMIcylz69ZNQeCSBpFVisHd8Mc7Iql ruyOmkc1T6TFE9Ni+RbjoxOosFyiNP9JsklpKhtYqg/XMpjoC+2x+Kpo5JoD1w+zEa42 F+uDWkCDhEGYnsImFx0otIulVX2zcV505w4YAfUDb/9jUO5hvrNRzwAM9GuqMxtimKVF QcnfhGh7fcWNLDTmjcqYV+KZkRK4q6+VX24ssJAOnyPNSdtIw7+WIU6oyqpA4YTA1PLC V57A== X-Gm-Message-State: ALoCoQlaD12UFINzTAfuELX584Bo+JG1TYjG1j9pOEbC69nppNCYfuMFWLri4bjO6TlNjQE7JJY9D35VSlpR1hhQtXz6/zg1crCJUTzE7kY60gkkAc0xDHHzo+4rOgKId2ioWhgcuqypfmw31CIoiMfoYv8ha1Ijro4ydaLHVoLPhbFtL2pX484= X-Received: by 10.194.206.38 with SMTP id ll6mr15616704wjc.116.1444984093943; Fri, 16 Oct 2015 01:28:13 -0700 (PDT) Received: from cskiralys-MacBook-Air.local ([217.77.82.234]) by smtp.googlemail.com with ESMTPSA id jd7sm21138291wjb.19.2015.10.16.01.28.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 01:28:13 -0700 (PDT) To: Routing Over Low power and Lossy networks References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> <560EA05A.3080002@fbk.eu> <560F5C5E.8010806@fbk.eu> <982B626E107E334DBE601D979F31785C5C500798@szxeml558-mbs.china.huawei.com> From: Csaba Kiraly Message-ID: <5620B51C.1050103@fbk.eu> Date: Fri, 16 Oct 2015 10:28:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <982B626E107E334DBE601D979F31785C5C500798@szxeml558-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 08:28:21 -0000 Hi Rahul, On 16/10/15 08:50, Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs) wrote: > We have also implemented this end-to-end ACK feature in our solution in Huawei. And this end-to-end ACK has become important especially in context to bigger networks. Without this feature it is impossible for the node to know when to initiate the application traffic (especially bidirectional traffic, like Joakim mentioned). Secondly it also reduces network convergence time for bigger networks (of-course at the cost of additional ACK traffic), because the repairs are triggered soon when the ACKs do not arrive. We had found good performance improvements for 1K node network (with roughly 16 hops) and it certainly improves the network convergence time and the nodes have more deterministic way of knowing when to initiate the traffic. > > IMO, this extension will help in a big way. Glad to hear that you've came to the same conclusions. I think it really shows that the possibility is there among the lines of the RFC, but not spelled out in a way to make it evident. IMHO this could lead to interoperability problems, but I would be interested to know if anyone actually did interoperability tests between implementations going with different interpretations. You speak of additional ACK traffic, which suggests that you use both end-to-end ACKs and one-hop ACKs. Is this the case, or are you just referring to more ACKs because of more information and thus more events to react to? > > There are few more points: > 1. Can the E2E-ACK sent by the grounded root be aggregated ? This is possible with the E2E-ACK going one hop. What you mean by E2E-ACK going one hop? I've seen ACK traffic near the root being a problem in our tests, and ACK aggregation could be supported at low implementation overhead, so I think it is a good option. If we don't want to mandate support for it, we can still consider a capability flag such as the "F" flag mentioned below to make it optional and interoperable. > 2. Some guidelines on what timers the end nodes should use for DAO retry in case the E2E-ACK is not received. The timers need to be set to a conservative (higher) value otherwise the cumulative DAO retries will negatively impact the network. Reasonable values for timers really depend on the decision logic. More precisely, on whether nodes in the chain can only forward DAO-NACKs or could also act on them e.g. by trying another parent (which takes some time). Since we don't want to mandate the decision logic, agreeing on limits on the timers without limiting scalability could be tough. I think having guidelines is a good idea, but we should be careful not to limit implementations and deployments. What about a push-back mechanism which tells the originator of the DAO to slow down with retries? For example, as part of the ACK, you could set a the "S" flag with the following meaning: "while I was processing this, I've seen several identical DAOs from you". This wouldn't slow down the normal DAO sending, just the retry timeout. Then, how the end node should handle this flag can be left to the implementation. I don't think we need to mandate how the timeout should scale up and down, it will work even without mandating the logic. Regards, Csaba > > Regards, > Rahul > > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Csaba Kiraly > Sent: 03 October 2015 AM 10:11 > To: roll@ietf.org > Subject: Re: [Roll] Semantics of DAO ACK > > Since we were jumping through several topics around the DAO-ACK semantics in this thread, I wrote a quick memo of what had been brought up till now. I thought it might worth sharing: > > DAO-ACK semantics > ----------------- > > 1, ACK for DAO with multiple T+T [Joakim] > - status code 1-127, and copy rejected Target [Cenk] > - new option with individual status codes (same semantics as with multiple individual messages) [Csaba] > - send individual ACKs for each Target [Joakim] > - memory concerns, better to include Target in response [Joakim] > - “F” flag in DAO to request full ACK with T+T or partial ACK with status codes only [Csaba] > - meaning of status code [Pascal] > - enumeration > - both Joakim and we use this (not for multiple T+T, but to differentiate different reasons of DAO rejection) > - would need registry for interoperability [Pascal] > - metric: as “scalar degree of unwillingness” calculated based on available resources [Pascal] > - could be difficult to combine it into one scalar degree in one byte [Joakim, Csaba] > - might be better to put the resource info in DIO or in a DAO option [Csaba] > - ACK with rejected T+T and status code for each; relation to path control [Pascal] > - “All-or-nothing” flag in DAO [Joakim] > > 2, ACK semantics: one-hop vs. end-to-end context [Csaba] > - when speaking of end-to-end context, we do not refer to a DAO addressed directly to the root, like in non-storing, but to a different interpretation of the ACK of the one-hop DAO [Csaba, Joakim] > - used in Yanzi [Joakim] > - drafted advantages and disadvantages [Pascal, Csaba, Joakim] > - possible deadlock [Pascal] > - is it RFC6550? > - one-hop ACK is not enough info, needs end-to-end for decision logic [Csaba, Joakim] > > 3, fix meaning of status code 127 (just a typo in the RFC) [Csaba] > > 4, status code in ACK for No-path DAO not defined clearly [Csaba] > - only code 0 makes sense [Joakim] > - not using end-to-end context in this case [Joakim] > > 5, multiple DAO ACKs for same DAO [Joakim, Csaba] > - to handle multiple T+T [Joakim] > - to have both end-to-end and one-hop ACK semantics [Csaba] > > Disclaimer: this doesn't want to be a full summary, and I obviously skipped many detail in such a brief writeup. > > Cheers, > Csaba > > On 02/10/15 17:39, Joakim Eriksson wrote: >> From my perspective we really need the end-to-end ACK that is needed >> - the single hop ACK is of no use at all if you aim at building scalable RPL networks that have bi-directional communication. >> >> We have worked with this for quite a while at Yanzi Networks and I >> would say that if we get a deadlock somewhere that is probably an >> indication that the selected path/parent was a bad one and that the >> node should look for alternatives. If we instead would have gotten a >> DAO ACK over single-hop the node would assume connectivity - but be >> wrong and some other mechanism (usually the application) needs to kick >> in and trigger repairs. This is for me not the wanted behaviour and I >> rather take the risk of one or a few >> (short-term) dead-locks if a node in the path towards root reboots or in other ways is gone. >> >> Of course combining DAO ACK (end-to-end) with infinite lifetime routes >> is not an optimal configuration if there are many reboots and >> dead-locks. That is why we try to keep routing lifetime reasonably >> short >> (30 minutes) so that any routes that ended up being “stuck” somewhere >> will be garbage collected after a while. >> >> Best regards, >> — Joakim Eriksson, SICS >> >> >>> On 02 Oct 2015, at 17:18, Csaba Kiraly wrote: >>> >>> Hi Pascal, >>> >>> The core observation behind the end-to-end, or delayed ACK (at least on my side, I don't know for Joakim) is that while the one-hop NACK contains important information, the one-hop ACK is not really what you are interested in. In fact, implementations I've checked either don't even ask for it, or if they do, they still don't do anything on a positive ACK. If instead you delay ACKs, or in other words wait for all the parents to ACK, this ACK or NACK brings in an important piece of information. >>> >>> Notice that if your immediate parent would NACK, it would NACK immediately in both interpretations. Feedback only changes where things go well, or things go well till some point on the recursive path, but fail after. In the first, you get an ACK and you know you are reachable. In the latter, you do get to know the problem and you can act upon. Convergence is surely something that needs to be studied carefully, but I think delayed ACK will not create more issues than what you already have with the one-hop ACK. >>> >>> The point that I tried to raise when I brought this up, but maybe it wasn't clear, is that I think both are conformant to RFC6550. Which, if I'm correct, brings me to the point that clarifications might be needed about ACKs in an RFC to avoid interoperability problems, and I think it is needed independent of whether the end-to-end context is a good idea or not. You could even think of sending both types of ACKs, but that would bring the implementation out of RFC6550. >>> >>> Cheers, >>> Csaba >>> >>> On 02/10/15 15:04, Pascal Thubert (pthubert) wrote: >>>> Hello Joakim: >>>> >>>> What I read here boils down to a limited diffusion algorithm. We tried to avoid that in RPL because any movement within the convergence would cause a deadlock. IOW if every node waits for (all of) the parents to ack, then this recursively takes you to the root, and if any node in the chain moves or dies, the diffusion will not be complete. >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Joakim >>>>> Eriksson >>>>> Sent: jeudi 1 octobre 2015 22:11 >>>>> To: Routing Over Low power and Lossy networks >>>>> Subject: Re: [Roll] Semantics of DAO ACK >>>>> >>>>> >>>>>> On 01 Oct 2015, at 21:03, Csaba Kiraly wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 30/09/15 17:55, Joakim Eriksson wrote: >>>>>>>> On 30 Sep 2015, at 06:44, Csaba Kiraly wrote: >>>>>>>> >>>>>>>> Hello Joakim, >>>>>>>> >>>>>>>> I have also worked on the Contiki DAO-ACK code, enabling ACKs, >>>>> implementing fixes to the DAOSequence handling, and looking into >>>>> multiple targets. >>>>>>> Nice, I have a PR on Contiki now with what we have been doing to >>>>>>> get >>>>> Contiki RPL more scalable (but still only single targets / paths). >>>>>>>> What Cenk is saying sounds a reasonable hack, but the standard >>>>>>>> itself >>>>> is in my opinion a bit underspecified for the semantics of DAO-ACK >>>>> messages in several ways. >>>>>>> Yes, it is underspecified. There is need for clarifications and >>>>>>> more details >>>>> on the DAO / DAO ACK! >>>>>>>> My preferred solution for ACKing DAO messages with multiple >>>>>>>> targets >>>>> would be to have support for the same semantics that you would have >>>>> had with one DAO message per Target, i.e., I would prefer an option >>>>> field that gives an individual status for each Target. >>>>>>> Yes, but that would require more memory in the sending node to >>>>>>> keep >>>>> track of things or full specification of the target in the response. >>>>>>> I guess it might be solved by allowing multiple DAO ACKs for the >>>>>>> same >>>>> DAO and to have the Target options included in the DAO ACK. >>>>>> This is a compromise to consider for sure. If you look at my >>>>> implementation, you can see that I use the routing table entry to >>>>> match the DAO ACK, and I keep only DAOSequence (SEQ) as extra >>>>> state. I'm not sure it would work in all cases, but it did work for >>>>> the case I considered. I'm keeping only the SEQ, and I think this >>>>> is a must if you have no aggregation, and you want to match in case >>>>> you forward multiple DAOs before getting the ACK or timing out on >>>>> it. In fact, simply enabling ACKs in the original code was messing >>>>> up the match between DAOs and their ACKs because it wasn't even keeping track of the DAO sequence numbers. >>>>>> If you do aggregate ACKs, or you have more complex Target+Transit >>>>> scenarios, the game changes, and I don't know what would be the >>>>> balance between state you have to keep anyway and state you keep >>>>> just to be able to interpret a later ACK correctly. I think it is >>>>> implementation specific, so my suggestion would be a flag to >>>>> indicate whether you request full ACK (bumping back all T+T info >>>>> for rejected entries in the DAO) or a much smaller partial ACK with >>>>> SEQ and similar IDs only. This flag (lets call it F for now), could >>>>> go right next to K. As the DAO propagates, each node could set F >>>>> based on whether it is able to store and/or reproduce info (F not >>>>> set) or chose to remain stateless (set F ). This would exclude aggregation in the DAO-ACK sent down, but still allow for aggregation in the DAO sent up. >>>>>>>> To give another example of subtle problems with DAO-ACK, it was >>>>>>>> not >>>>> clear to me whether I want my implementation to ACK when the Target >>>>> is added to the routing table, or only when this node itself >>>>> receives an ACK for the same Target from its parent. Both makes >>>>> sense, with the former giving a quick one-hop ACK, while the latter >>>>> works as an end-to-end ACK, ensuring that the path is actually >>>>> built. Both look conformant to the standard, but I suppose the >>>>> original author was thinking of the former, and I can easily see >>>>> interoperability problems arising between two implementations using different semantics. >>>>>>> We did go for the end-to-end ACK to achieve better scalability. >>>>>>> There is to me no point having a route to the parent if it is not >>>>>>> possible to get >>>>> it all the way to root. But I totally agree - this is not obvious >>>>> from the RPL RFC either. >>>>>> Do you mean end-to-end ACK as in non-storing, or end-to-end ACK in >>>>>> the >>>>> sense that it is still addressed to the next hop but you delay ACK >>>>> till you know your parent (and all its parents) ACKed? >>>>> I mean end-to-end as in waiting for all the parents to ACK so that >>>>> before ACKing it is known that the route is properly installed where it needs to. >>>>> >>>>>>> Do you have your Contiki code somewhere in the open-source? >>>>>> I did some cleanup and pushed the clean part of the code to github: >>>>>> https://github.com/cskiraly/contiki/tree/DAO-NACK >>>>>> It is not yet rebased to the latest master, but it should apply. I >>>>>> suppose >>>>> describing it would be too off-topic for the list. >>>>>> There is also the more experimental part of the code in a PR, if interested. >>>>> Ok - I’ll take a look! >>>>> >>>>> BTW: We have done a few deployments using our implementation using >>>>> Yanzi networks products - take a look at this video where 1000 >>>>> nodes is deployed with Contiki RPL + our fixes and 20 neighbors and >>>>> routes per node. If without our fixes it would not work since >>>>> Contiki RPL did not allow scaling beyond number of neighbors and >>>>> routes / node that well before these fixes. >>>>> >>>>> http://www.yanzi.se/video.jsp?id=7 >>>>> >>>>> Best regards, >>>>> — Joakim Eriksson >>>>> >>>>>> Best regards, >>>>>> Csaba >>>>>>> Best regards, >>>>>>> — Joakim >>>>>>> >>>>>>>> Best regards, >>>>>>>> Csaba >>>>>>>> >>>>>>>> On 29/09/15 23:08, Cenk Gündogan wrote: >>>>>>>>> Hello Joakim, >>>>>>>>> >>>>>>>>> This is an interesting question and I also couldn't find any >>>>>>>>> answers in >>>>> RFC 6550. >>>>>>>>> However, my thoughts on this are as follows: >>>>>>>>> Since a sub-set of the announced RPL targets could have been >>>>>>>>> accepted before filling up the routing table (e.g.), I would >>>>>>>>> choose a >>>>> status code between 1 and 127. >>>>>>>>> I would expect a node to choose another parent if a more >>>>>>>>> aggressive >>>>> status code is received ([128-255]). >>>>>>>>> But a full routing table can have free space again until the >>>>>>>>> next or any >>>>> subsequent DAO arrives .. >>>>>>>>> therefore I prefer a "mild rejection" with a status code of [1-127]. >>>>>>>>> >>>>>>>>> To give some feedback to the originator of the DAO, it might be >>>>>>>>> sensible to copy the rejected RPL Target options from the >>>>>>>>> affected DAO to the DAO-ACK, so that the originator is fully >>>>>>>>> aware of which >>>>> Target prefixes got rejected (and which ones got accepted, implicitly). >>>>>>>>> I would choose this method, because it doesn't require the >>>>>>>>> originator of the DAO to save any extra state about the DAO and >>>>>>>>> its >>>>> contents. >>>>>>>>> Nonetheless, everything I wrote is nonconform and I am also >>>>>>>>> interested in the RPL experts' opinions and solutions. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Cenk >>>>>>>>> >>>>>>>>> On 29.09.2015 21:44, Joakim Eriksson wrote: >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>> I have spend quite some time to get a more stable >>>>>>>>>> implementation of DAO handling for Contiki RPL and I am >>>>>>>>>> currently looking into DAO aggregation. But I realised that it >>>>>>>>>> is for me not 100% clear what a node that receives a DAO with >>>>>>>>>> several prefixes to be registered but can only accept a >>>>>>>>>> sub-set of them. Should it be a >>>>> DAO_NACK in this case or is there any other way to handle that case? >>>>>>>>>> If each would have been sent separately it is obvious that the >>>>>>>>>> receiving node can do a NACK when the routing table is full >>>>>>>>>> and therefore it is possible to get fine-grained answers. But >>>>>>>>>> with >>>>> aggregation of DAOs this is not the case. >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> — Joakim Eriksson, SICS >>>>>>>>>> _______________________________________________ >>>>>>>>>> Roll mailing list >>>>>>>>>> Roll@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>>> _______________________________________________ >>>>>>>>> Roll mailing list >>>>>>>>> Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Oct 16 05:10:09 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942A1A9302 for ; Fri, 16 Oct 2015 05:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHMkdn7x02c5 for ; Fri, 16 Oct 2015 05:10:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B8C1A92FC for ; Fri, 16 Oct 2015 05:10:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCQ14672; Fri, 16 Oct 2015 12:10:00 +0000 (GMT) Received: from SZXEML423-HUB.china.huawei.com (10.82.67.154) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 13:09:57 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.53]) by SZXEML423-HUB.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 20:09:34 +0800 From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Semantics of DAO ACK Thread-Index: AQHQ+u9ZrOL6bWvrvE6fSZTBFoYmXJ5TeemAgAB/gwCAALuCgIABxtQAgAAS9ACAARsrAIAAJWsAgAAFz4CAANpTAIAVEedw//+b4ACAAJKcAA== Date: Fri, 16 Oct 2015 12:09:33 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5C5007EE@szxeml558-mbs.china.huawei.com> References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> <560EA05A.3080002@fbk.eu> <560F5C5E.8010806@fbk.eu> <982B626E107E334DBE601D979F31785C5C500798@szxeml558-mbs.china.huawei.com> <5620B51C.1050103@fbk.eu> In-Reply-To: <5620B51C.1050103@fbk.eu> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.215.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:10:07 -0000 SGkgQ3NhYmEsDQoNClJlc3BvbnNlcyBpbmxpbmUuLi4NCg0KUmVnYXJkcywNClJhaHVsDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3NhYmEgS2lyYWx5DQpTZW50OiAxNiBPY3RvYmVyIDIw MTUgUE0gMDE6NTgNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jr cw0KU3ViamVjdDogUmU6IFtSb2xsXSBTZW1hbnRpY3Mgb2YgREFPIEFDSw0KDQpIaSBSYWh1bCwN Cg0KT24gMTYvMTAvMTUgMDg6NTAsIFJhaHVsIEFydmluZCBKYWRoYXYgKFJhaHVsIEFydmluZCBK YWRoYXYsIDIwMTIgTGFicykNCndyb3RlOg0KPiBXZSBoYXZlIGFsc28gaW1wbGVtZW50ZWQgdGhp cyBlbmQtdG8tZW5kIEFDSyBmZWF0dXJlIGluIG91ciBzb2x1dGlvbiBpbiBIdWF3ZWkuIEFuZCB0 aGlzIGVuZC10by1lbmQgQUNLIGhhcyBiZWNvbWUgaW1wb3J0YW50IGVzcGVjaWFsbHkgaW4gY29u dGV4dCB0byBiaWdnZXIgbmV0d29ya3MuIFdpdGhvdXQgdGhpcyBmZWF0dXJlIGl0IGlzIGltcG9z c2libGUgZm9yIHRoZSBub2RlIHRvIGtub3cgd2hlbiB0byBpbml0aWF0ZSB0aGUgYXBwbGljYXRp b24gdHJhZmZpYyAoZXNwZWNpYWxseSBiaWRpcmVjdGlvbmFsIHRyYWZmaWMsIGxpa2UgSm9ha2lt IG1lbnRpb25lZCkuIFNlY29uZGx5IGl0IGFsc28gcmVkdWNlcyBuZXR3b3JrIGNvbnZlcmdlbmNl IHRpbWUgZm9yIGJpZ2dlciBuZXR3b3JrcyAob2YtY291cnNlIGF0IHRoZSBjb3N0IG9mIGFkZGl0 aW9uYWwgQUNLIHRyYWZmaWMpLCBiZWNhdXNlIHRoZSByZXBhaXJzIGFyZSB0cmlnZ2VyZWQgc29v biB3aGVuIHRoZSBBQ0tzIGRvIG5vdCBhcnJpdmUuIFdlIGhhZCBmb3VuZCBnb29kIHBlcmZvcm1h bmNlIGltcHJvdmVtZW50cyBmb3IgMUsgbm9kZSBuZXR3b3JrICh3aXRoIHJvdWdobHkgMTYgaG9w cykgYW5kIGl0IGNlcnRhaW5seSBpbXByb3ZlcyB0aGUgbmV0d29yayBjb252ZXJnZW5jZSB0aW1l IGFuZCB0aGUgbm9kZXMgaGF2ZSAgbW9yZSBkZXRlcm1pbmlzdGljIHdheSBvZiBrbm93aW5nIHdo ZW4gdG8gaW5pdGlhdGUgdGhlIHRyYWZmaWMuDQo+DQo+IElNTywgdGhpcyBleHRlbnNpb24gd2ls bCBoZWxwIGluIGEgYmlnIHdheS4NCkdsYWQgdG8gaGVhciB0aGF0IHlvdSd2ZSBjYW1lIHRvIHRo ZSBzYW1lIGNvbmNsdXNpb25zLiBJIHRoaW5rIGl0IHJlYWxseSBzaG93cyB0aGF0IHRoZSBwb3Nz aWJpbGl0eSBpcyB0aGVyZSBhbW9uZyB0aGUgbGluZXMgb2YgdGhlIFJGQywgYnV0IG5vdCBzcGVs bGVkIG91dCBpbiBhIHdheSB0byBtYWtlIGl0IGV2aWRlbnQuIElNSE8gdGhpcyBjb3VsZCBsZWFk IHRvIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMsIGJ1dCBJIHdvdWxkIGJlIGludGVyZXN0ZWQg dG8ga25vdyBpZiBhbnlvbmUgYWN0dWFsbHkgZGlkIGludGVyb3BlcmFiaWxpdHkgdGVzdHMgYmV0 d2VlbiBpbXBsZW1lbnRhdGlvbnMgZ29pbmcgd2l0aCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25z Lg0KDQpZb3Ugc3BlYWsgb2YgYWRkaXRpb25hbCBBQ0sgdHJhZmZpYywgd2hpY2ggc3VnZ2VzdHMg dGhhdCB5b3UgdXNlIGJvdGggZW5kLXRvLWVuZCBBQ0tzIGFuZCBvbmUtaG9wIEFDS3MuIElzIHRo aXMgdGhlIGNhc2UsIG9yIGFyZSB5b3UganVzdCByZWZlcnJpbmcgdG8gbW9yZSBBQ0tzIGJlY2F1 c2Ugb2YgbW9yZSBpbmZvcm1hdGlvbiBhbmQgdGh1cyBtb3JlIGV2ZW50cyB0byByZWFjdCB0bz8N Cg0KLS1bUkpdLS0NClRoZSBhZGRpdGlvbmFsIEFDSyB0cmFmZmljIHRoYXQgSSB0YWxrIG9mIGlz IG9mIHRoZSBlbmQtdG8tZW5kIEFDS3MgYWxvbmUuIE9uZS1ob3AgQUNLcyBhcmUgbm90IHVzZWZ1 bCBpbiBhbnkgY2FzZSwgaW1vLCBhbmQgd2UgbmV2ZXIgaGF2ZSB1c2VkIGl0LiBJIG0gcmVmZXJy aW5nIHRvIHRoZSBhZGRpdGlvbmFsIHRyYWZmaWMgZ2VuZXJhdGVkIGZvciBFMkUtQUNLcyBhbmQg cmV0cmFuc21pc3Npb25zIG9mIERBT3Mgb24gbm90IHJlY2VwdGlvbiBvZiB0aGVzZSBBQ0tzLiBN eSBwb2ludCBpcywgaW4gYSBiaWdnZXIgbmV0d29yaywgdGhlcmUgaXMgc2NvcGUgb2YgYWdncmVn YXRpbmcgdGhlc2UgZG93bnN0cmVhbSBBQ0tzIHByb3ZpZGVkIHRoZXNlIEFDS3MgYXJlIHNlbnQg YmFjayB0byB0aGUgbm9kZXMgb24gaG9wLWJ5LWhvcCBiYXNpcyAoanVzdCBsaWtlIERBTyB0cmF2 ZWwgdXBzdHJlYW0gaG9wLWJ5LWhvcCwgRTJFIGFnZ3JlZ2F0ZWQgQWNrcyBjYW4gdHJhdmVsIGRv d25zdHJlYW0gaG9wLWJ5LWhvcCkuIEJ1dCB0aGVuIGxpa2UgREFPLCB0aGVzZSBFMkUtQUNLcyBh bHNvIG5lZWQgdG8gY2FycnkgdGFyZ2V0IGluZm9ybWF0aW9uIGluIHRoZSBwYXlsb2FkIGZvciBp dCB0byBiZSBhZ2dyZWdhdGVkLg0KLS1bUkotRW5kXS0tDQoNCg0KPg0KPiBUaGVyZSBhcmUgZmV3 IG1vcmUgcG9pbnRzOg0KPiAxLiBDYW4gdGhlIEUyRS1BQ0sgc2VudCBieSB0aGUgZ3JvdW5kZWQg cm9vdCBiZSBhZ2dyZWdhdGVkID8gVGhpcyBpcyBwb3NzaWJsZSB3aXRoIHRoZSBFMkUtQUNLIGdv aW5nIG9uZSBob3AuDQpXaGF0IHlvdSBtZWFuIGJ5IEUyRS1BQ0sgZ29pbmcgb25lIGhvcD8gSSd2 ZSBzZWVuIEFDSyB0cmFmZmljIG5lYXIgdGhlIHJvb3QgYmVpbmcgYSBwcm9ibGVtIGluIG91ciB0 ZXN0cywgYW5kIEFDSyBhZ2dyZWdhdGlvbiBjb3VsZCBiZSBzdXBwb3J0ZWQgYXQgbG93IGltcGxl bWVudGF0aW9uIG92ZXJoZWFkLCBzbyBJIHRoaW5rIGl0IGlzIGEgZ29vZCBvcHRpb24uIElmIHdl IGRvbid0IHdhbnQgdG8gbWFuZGF0ZSBzdXBwb3J0IGZvciBpdCwgd2UgY2FuIHN0aWxsIGNvbnNp ZGVyIGEgY2FwYWJpbGl0eSBmbGFnIHN1Y2ggYXMgdGhlICJGIiBmbGFnIG1lbnRpb25lZCBiZWxv dyB0byBtYWtlIGl0IG9wdGlvbmFsIGFuZCBpbnRlcm9wZXJhYmxlLg0KDQotLVtSSl0tLQ0KU29y cnkgbXkgc3RhdGVtZW50IGFib3ZlIHdhcyBpbmNvcnJlY3QuIFNlbnQgdGhlIG1haWwgaW4gYSBo YXN0ZS4gSSBtZWFudCAiRTJFLUFDSyBnb2luZyBvbiBob3AtYnktaG9wIGJhc2lzIi4uIFRoaXMg aXMgbmVlZGVkIGZvciBhZ2dyZWdhdGlvbiB0byB3b3JrLiBCdXQgYXMgbWVudGlvbmVkIGFib3Zl LCBmb3IgYWdncmVnYXRpb24gdG8gd29yaywgb25lIG5lZWRzIHRvIGFkZCB0YXJnZXQgaW5mb3Jt YXRpb24gYmFjayBpbiB0aGUgRTJFLUFDSy4NCi0tW1JKLUVuZF0tLQ0KDQo+IDIuIFNvbWUgZ3Vp ZGVsaW5lcyBvbiB3aGF0IHRpbWVycyB0aGUgZW5kIG5vZGVzIHNob3VsZCB1c2UgZm9yIERBTyBy ZXRyeSBpbiBjYXNlIHRoZSBFMkUtQUNLIGlzIG5vdCByZWNlaXZlZC4gVGhlIHRpbWVycyBuZWVk IHRvIGJlIHNldCB0byBhIGNvbnNlcnZhdGl2ZSAoaGlnaGVyKSB2YWx1ZSBvdGhlcndpc2UgdGhl IGN1bXVsYXRpdmUgREFPIHJldHJpZXMgd2lsbCBuZWdhdGl2ZWx5IGltcGFjdCB0aGUgbmV0d29y ay4NClJlYXNvbmFibGUgdmFsdWVzIGZvciB0aW1lcnMgcmVhbGx5IGRlcGVuZCBvbiB0aGUgZGVj aXNpb24gbG9naWMuIE1vcmUgcHJlY2lzZWx5LCBvbiB3aGV0aGVyIG5vZGVzIGluIHRoZSBjaGFp biBjYW4gb25seSBmb3J3YXJkIERBTy1OQUNLcyBvciBjb3VsZCBhbHNvIGFjdCBvbiB0aGVtIGUu Zy4gYnkgdHJ5aW5nIGFub3RoZXIgcGFyZW50ICh3aGljaCB0YWtlcyBzb21lIHRpbWUpLiBTaW5j ZSB3ZSBkb24ndCB3YW50IHRvIG1hbmRhdGUgdGhlIGRlY2lzaW9uIGxvZ2ljLCBhZ3JlZWluZyBv biBsaW1pdHMgb24gdGhlIHRpbWVycyB3aXRob3V0IGxpbWl0aW5nIHNjYWxhYmlsaXR5IGNvdWxk IGJlIHRvdWdoLiBJIHRoaW5rIGhhdmluZyBndWlkZWxpbmVzIGlzIGEgZ29vZCBpZGVhLCBidXQg d2Ugc2hvdWxkIGJlIGNhcmVmdWwgbm90IHRvIGxpbWl0IGltcGxlbWVudGF0aW9ucyBhbmQgZGVw bG95bWVudHMuDQoNCldoYXQgYWJvdXQgYSBwdXNoLWJhY2sgbWVjaGFuaXNtIHdoaWNoIHRlbGxz IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBEQU8gdG8gc2xvdyBkb3duIHdpdGggcmV0cmllcz8gRm9y IGV4YW1wbGUsIGFzIHBhcnQgb2YgdGhlIEFDSywgeW91IGNvdWxkIHNldCBhIHRoZSAiUyIgZmxh ZyB3aXRoIHRoZSBmb2xsb3dpbmcgbWVhbmluZzogIndoaWxlIEkgd2FzIHByb2Nlc3NpbmcgdGhp cywgSSd2ZSBzZWVuIHNldmVyYWwgaWRlbnRpY2FsIERBT3MgZnJvbSB5b3UiLiBUaGlzIHdvdWxk bid0IHNsb3cgZG93biB0aGUgbm9ybWFsIERBTyBzZW5kaW5nLCBqdXN0IHRoZSByZXRyeSB0aW1l b3V0LiBUaGVuLCBob3cgdGhlIGVuZCBub2RlIHNob3VsZCBoYW5kbGUgdGhpcyBmbGFnIGNhbiBi ZSBsZWZ0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1h bmRhdGUgaG93IHRoZSB0aW1lb3V0IHNob3VsZCBzY2FsZSB1cCBhbmQgZG93biwgaXQgd2lsbCB3 b3JrIGV2ZW4gd2l0aG91dCBtYW5kYXRpbmcgdGhlIGxvZ2ljLg0KDQotLVtSSl0tLQ0KSSB0aGlu ayB0aGlzIGZsYWcgaXMgbm90IG5lY2Vzc2FyeSwgc2luY2UgaWYgdGhlIEUyRS1BQ0sgcmVhY2hl cyB0aGUgbm9kZSB0aGVuIGFueXdheXMgaXQgd2lsbCBjZWFzZSBzZW5kaW5nIERBTy4NCi0tW1JK LUVuZF0tLQ0KDQpSZWdhcmRzLA0KQ3NhYmENCg0KPg0KPiBSZWdhcmRzLA0KPiBSYWh1bA0KPg0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2xsIFttYWlsdG86cm9s bC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3NhYmEgS2lyYWx5DQo+IFNlbnQ6IDAz IE9jdG9iZXIgMjAxNSBBTSAxMDoxMQ0KPiBUbzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW1JvbGxdIFNlbWFudGljcyBvZiBEQU8gQUNLDQo+DQo+IFNpbmNlIHdlIHdlcmUganVtcGlu ZyB0aHJvdWdoIHNldmVyYWwgdG9waWNzIGFyb3VuZCB0aGUgREFPLUFDSyBzZW1hbnRpY3MgaW4g dGhpcyB0aHJlYWQsIEkgd3JvdGUgYSBxdWljayBtZW1vIG9mIHdoYXQgaGFkIGJlZW4gYnJvdWdo dCB1cCB0aWxsIG5vdy4gSSB0aG91Z2h0IGl0IG1pZ2h0IHdvcnRoIHNoYXJpbmc6DQo+DQo+IERB Ty1BQ0sgc2VtYW50aWNzDQo+IC0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IDEsIEFDSyBmb3IgREFP IHdpdGggbXVsdGlwbGUgVCtUIFtKb2FraW1dDQo+ICAgIC0gc3RhdHVzIGNvZGUgMS0xMjcsIGFu ZCBjb3B5IHJlamVjdGVkIFRhcmdldCBbQ2Vua10NCj4gICAgLSBuZXcgb3B0aW9uIHdpdGggaW5k aXZpZHVhbCBzdGF0dXMgY29kZXMgKHNhbWUgc2VtYW50aWNzIGFzIHdpdGggbXVsdGlwbGUgaW5k aXZpZHVhbCBtZXNzYWdlcykgW0NzYWJhXQ0KPiAgICAgIC0gc2VuZCBpbmRpdmlkdWFsIEFDS3Mg Zm9yIGVhY2ggVGFyZ2V0IFtKb2FraW1dDQo+ICAgICAgICAtIG1lbW9yeSBjb25jZXJucywgYmV0 dGVyIHRvIGluY2x1ZGUgVGFyZ2V0IGluIHJlc3BvbnNlIFtKb2FraW1dDQo+ICAgICAgICAgIC0g 4oCcRuKAnSBmbGFnIGluIERBTyB0byByZXF1ZXN0IGZ1bGwgQUNLIHdpdGggVCtUIG9yIHBhcnRp YWwgQUNLIHdpdGggc3RhdHVzIGNvZGVzIG9ubHkgW0NzYWJhXQ0KPiAgICAtIG1lYW5pbmcgb2Yg c3RhdHVzIGNvZGUgW1Bhc2NhbF0NCj4gICAgICAtIGVudW1lcmF0aW9uDQo+ICAgICAgICAtIGJv dGggSm9ha2ltIGFuZCB3ZSB1c2UgdGhpcyAobm90IGZvciBtdWx0aXBsZSBUK1QsIGJ1dCB0byBk aWZmZXJlbnRpYXRlIGRpZmZlcmVudCByZWFzb25zIG9mIERBTyByZWplY3Rpb24pDQo+ICAgICAg ICAtIHdvdWxkIG5lZWQgcmVnaXN0cnkgZm9yIGludGVyb3BlcmFiaWxpdHkgW1Bhc2NhbF0NCj4g ICAgICAtIG1ldHJpYzogYXMg4oCcc2NhbGFyIGRlZ3JlZSBvZiB1bndpbGxpbmduZXNz4oCdIGNh bGN1bGF0ZWQgYmFzZWQgb24gYXZhaWxhYmxlIHJlc291cmNlcyBbUGFzY2FsXQ0KPiAgICAgICAg LSBjb3VsZCBiZSBkaWZmaWN1bHQgdG8gY29tYmluZSBpdCBpbnRvIG9uZSBzY2FsYXIgZGVncmVl IGluIG9uZSBieXRlIFtKb2FraW0sIENzYWJhXQ0KPiAgICAgICAgLSBtaWdodCBiZSBiZXR0ZXIg dG8gcHV0IHRoZSByZXNvdXJjZSBpbmZvIGluIERJTyBvciBpbiBhIERBTyBvcHRpb24gW0NzYWJh XQ0KPiAgICAtIEFDSyB3aXRoIHJlamVjdGVkIFQrVCBhbmQgc3RhdHVzIGNvZGUgZm9yIGVhY2g7 IHJlbGF0aW9uIHRvIHBhdGggY29udHJvbCBbUGFzY2FsXQ0KPiAgICAtIOKAnEFsbC1vci1ub3Ro aW5n4oCdIGZsYWcgaW4gREFPIFtKb2FraW1dDQo+DQo+IDIsIEFDSyBzZW1hbnRpY3M6IG9uZS1o b3AgdnMuIGVuZC10by1lbmQgY29udGV4dCBbQ3NhYmFdDQo+ICAgIC0gd2hlbiBzcGVha2luZyBv ZiBlbmQtdG8tZW5kIGNvbnRleHQsIHdlIGRvIG5vdCByZWZlciB0byBhIERBTyBhZGRyZXNzZWQg ZGlyZWN0bHkgdG8gdGhlIHJvb3QsIGxpa2UgaW4gbm9uLXN0b3JpbmcsIGJ1dCB0byBhIGRpZmZl cmVudCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgQUNLIG9mIHRoZSBvbmUtaG9wIERBTyBbQ3NhYmEs IEpvYWtpbV0NCj4gICAgLSB1c2VkIGluIFlhbnppIFtKb2FraW1dDQo+ICAgIC0gZHJhZnRlZCBh ZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIFtQYXNjYWwsIENzYWJhLCBKb2FraW1dDQo+ICAg ICAgLSBwb3NzaWJsZSBkZWFkbG9jayBbUGFzY2FsXQ0KPiAgICAgIC0gaXMgaXQgUkZDNjU1MD8N Cj4gICAgICAtIG9uZS1ob3AgQUNLIGlzIG5vdCBlbm91Z2ggaW5mbywgbmVlZHMgZW5kLXRvLWVu ZCBmb3IgZGVjaXNpb24gDQo+IGxvZ2ljIFtDc2FiYSwgSm9ha2ltXQ0KPg0KPiAzLCBmaXggbWVh bmluZyBvZiBzdGF0dXMgY29kZSAxMjcgKGp1c3QgYSB0eXBvIGluIHRoZSBSRkMpIFtDc2FiYV0N Cj4NCj4gNCwgc3RhdHVzIGNvZGUgaW4gQUNLIGZvciBOby1wYXRoIERBTyBub3QgZGVmaW5lZCBj bGVhcmx5IFtDc2FiYV0NCj4gICAgLSBvbmx5IGNvZGUgMCBtYWtlcyBzZW5zZSBbSm9ha2ltXQ0K PiAgICAtIG5vdCB1c2luZyBlbmQtdG8tZW5kIGNvbnRleHQgaW4gdGhpcyBjYXNlIFtKb2FraW1d DQo+DQo+IDUsIG11bHRpcGxlIERBTyBBQ0tzIGZvciBzYW1lIERBTyBbSm9ha2ltLCBDc2FiYV0N Cj4gICAgLSB0byBoYW5kbGUgbXVsdGlwbGUgVCtUIFtKb2FraW1dDQo+ICAgIC0gdG8gaGF2ZSBi b3RoIGVuZC10by1lbmQgYW5kIG9uZS1ob3AgQUNLIHNlbWFudGljcyBbQ3NhYmFdDQo+DQo+IERp c2NsYWltZXI6IHRoaXMgZG9lc24ndCB3YW50IHRvIGJlIGEgZnVsbCBzdW1tYXJ5LCBhbmQgSSBv YnZpb3VzbHkgc2tpcHBlZCBtYW55IGRldGFpbCBpbiBzdWNoIGEgYnJpZWYgd3JpdGV1cC4NCj4N Cj4gQ2hlZXJzLA0KPiBDc2FiYQ0KPg0KPiBPbiAwMi8xMC8xNSAxNzozOSwgSm9ha2ltIEVyaWtz c29uIHdyb3RlOg0KPj4gICBGcm9tIG15IHBlcnNwZWN0aXZlIHdlIHJlYWxseSBuZWVkIHRoZSBl bmQtdG8tZW5kIEFDSyB0aGF0IGlzIA0KPj4gbmVlZGVkDQo+PiAtIHRoZSBzaW5nbGUgaG9wIEFD SyBpcyBvZiBubyB1c2UgYXQgYWxsIGlmIHlvdSBhaW0gYXQgYnVpbGRpbmcgc2NhbGFibGUgUlBM IG5ldHdvcmtzIHRoYXQgaGF2ZSBiaS1kaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uLg0KPj4NCj4+ IFdlIGhhdmUgd29ya2VkIHdpdGggdGhpcyBmb3IgcXVpdGUgYSB3aGlsZSBhdCBZYW56aSBOZXR3 b3JrcyBhbmQgSSANCj4+IHdvdWxkIHNheSB0aGF0IGlmIHdlIGdldCBhIGRlYWRsb2NrIHNvbWV3 aGVyZSB0aGF0IGlzIHByb2JhYmx5IGFuIA0KPj4gaW5kaWNhdGlvbiB0aGF0IHRoZSBzZWxlY3Rl ZCBwYXRoL3BhcmVudCB3YXMgYSBiYWQgb25lIGFuZCB0aGF0IHRoZSANCj4+IG5vZGUgc2hvdWxk IGxvb2sgZm9yIGFsdGVybmF0aXZlcy4gSWYgd2UgaW5zdGVhZCB3b3VsZCBoYXZlIGdvdHRlbiBh IA0KPj4gREFPIEFDSyBvdmVyIHNpbmdsZS1ob3AgdGhlIG5vZGUgd291bGQgYXNzdW1lIGNvbm5l Y3Rpdml0eSAtIGJ1dCBiZSANCj4+IHdyb25nIGFuZCBzb21lIG90aGVyIG1lY2hhbmlzbSAodXN1 YWxseSB0aGUgYXBwbGljYXRpb24pIG5lZWRzIHRvIA0KPj4ga2ljayBpbiBhbmQgdHJpZ2dlciBy ZXBhaXJzLiBUaGlzIGlzIGZvciBtZSBub3QgdGhlIHdhbnRlZCBiZWhhdmlvdXIgDQo+PiBhbmQg SSByYXRoZXIgdGFrZSB0aGUgcmlzayBvZiBvbmUgb3IgYSBmZXcNCj4+IChzaG9ydC10ZXJtKSBk ZWFkLWxvY2tzIGlmIGEgbm9kZSBpbiB0aGUgcGF0aCB0b3dhcmRzIHJvb3QgcmVib290cyBvciBp biBvdGhlciB3YXlzIGlzIGdvbmUuDQo+Pg0KPj4gT2YgY291cnNlIGNvbWJpbmluZyBEQU8gQUNL IChlbmQtdG8tZW5kKSB3aXRoIGluZmluaXRlIGxpZmV0aW1lIA0KPj4gcm91dGVzIGlzIG5vdCBh biBvcHRpbWFsIGNvbmZpZ3VyYXRpb24gaWYgdGhlcmUgYXJlIG1hbnkgcmVib290cyBhbmQgDQo+ PiBkZWFkLWxvY2tzLiBUaGF0IGlzIHdoeSB3ZSB0cnkgdG8ga2VlcCByb3V0aW5nIGxpZmV0aW1l IHJlYXNvbmFibHkgDQo+PiBzaG9ydA0KPj4gKDMwIG1pbnV0ZXMpIHNvIHRoYXQgYW55IHJvdXRl cyB0aGF0IGVuZGVkIHVwIGJlaW5nIOKAnHN0dWNr4oCdIHNvbWV3aGVyZSANCj4+IHdpbGwgYmUg Z2FyYmFnZSBjb2xsZWN0ZWQgYWZ0ZXIgYSB3aGlsZS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+ PiDigJQgSm9ha2ltIEVyaWtzc29uLCBTSUNTDQo+Pg0KPj4NCj4+PiBPbiAwMiBPY3QgMjAxNSwg YXQgMTc6MTgsIENzYWJhIEtpcmFseSA8a2lyYWx5QGZiay5ldT4gd3JvdGU6DQo+Pj4NCj4+PiBI aSBQYXNjYWwsDQo+Pj4NCj4+PiBUaGUgY29yZSBvYnNlcnZhdGlvbiBiZWhpbmQgdGhlIGVuZC10 by1lbmQsIG9yIGRlbGF5ZWQgQUNLIChhdCBsZWFzdCBvbiBteSBzaWRlLCBJIGRvbid0IGtub3cg Zm9yIEpvYWtpbSkgaXMgdGhhdCB3aGlsZSB0aGUgb25lLWhvcCBOQUNLIGNvbnRhaW5zIGltcG9y dGFudCBpbmZvcm1hdGlvbiwgdGhlIG9uZS1ob3AgQUNLIGlzIG5vdCByZWFsbHkgd2hhdCB5b3Ug YXJlIGludGVyZXN0ZWQgaW4uIEluIGZhY3QsIGltcGxlbWVudGF0aW9ucyBJJ3ZlIGNoZWNrZWQg ZWl0aGVyIGRvbid0IGV2ZW4gYXNrIGZvciBpdCwgb3IgaWYgdGhleSBkbywgdGhleSBzdGlsbCBk b24ndCBkbyBhbnl0aGluZyBvbiBhIHBvc2l0aXZlIEFDSy4gSWYgaW5zdGVhZCB5b3UgZGVsYXkg QUNLcywgb3IgaW4gb3RoZXIgd29yZHMgd2FpdCBmb3IgYWxsIHRoZSBwYXJlbnRzIHRvIEFDSywg dGhpcyBBQ0sgb3IgTkFDSyBicmluZ3MgaW4gYW4gaW1wb3J0YW50IHBpZWNlIG9mIGluZm9ybWF0 aW9uLg0KPj4+DQo+Pj4gTm90aWNlIHRoYXQgaWYgeW91ciBpbW1lZGlhdGUgcGFyZW50IHdvdWxk IE5BQ0ssIGl0IHdvdWxkIE5BQ0sgaW1tZWRpYXRlbHkgaW4gYm90aCBpbnRlcnByZXRhdGlvbnMu IEZlZWRiYWNrIG9ubHkgY2hhbmdlcyB3aGVyZSB0aGluZ3MgZ28gd2VsbCwgb3IgdGhpbmdzIGdv IHdlbGwgdGlsbCBzb21lIHBvaW50IG9uIHRoZSByZWN1cnNpdmUgcGF0aCwgYnV0IGZhaWwgYWZ0 ZXIuIEluIHRoZSBmaXJzdCwgeW91IGdldCBhbiBBQ0sgYW5kIHlvdSBrbm93IHlvdSBhcmUgcmVh Y2hhYmxlLiBJbiB0aGUgbGF0dGVyLCB5b3UgZG8gZ2V0IHRvIGtub3cgdGhlIHByb2JsZW0gYW5k IHlvdSBjYW4gYWN0IHVwb24uIENvbnZlcmdlbmNlIGlzIHN1cmVseSBzb21ldGhpbmcgdGhhdCBu ZWVkcyB0byBiZSBzdHVkaWVkIGNhcmVmdWxseSwgYnV0IEkgdGhpbmsgZGVsYXllZCBBQ0sgd2ls bCBub3QgY3JlYXRlIG1vcmUgaXNzdWVzIHRoYW4gd2hhdCB5b3UgYWxyZWFkeSBoYXZlIHdpdGgg dGhlIG9uZS1ob3AgQUNLLg0KPj4+DQo+Pj4gVGhlIHBvaW50IHRoYXQgSSB0cmllZCB0byByYWlz ZSB3aGVuIEkgYnJvdWdodCB0aGlzIHVwLCBidXQgbWF5YmUgaXQgd2Fzbid0IGNsZWFyLCBpcyB0 aGF0IEkgdGhpbmsgYm90aCBhcmUgY29uZm9ybWFudCB0byBSRkM2NTUwLiBXaGljaCwgaWYgSSdt IGNvcnJlY3QsIGJyaW5ncyBtZSB0byB0aGUgcG9pbnQgdGhhdCBjbGFyaWZpY2F0aW9ucyBtaWdo dCBiZSBuZWVkZWQgYWJvdXQgQUNLcyBpbiBhbiBSRkMgdG8gYXZvaWQgaW50ZXJvcGVyYWJpbGl0 eSBwcm9ibGVtcywgYW5kIEkgdGhpbmsgaXQgaXMgbmVlZGVkIGluZGVwZW5kZW50IG9mIHdoZXRo ZXIgdGhlIGVuZC10by1lbmQgY29udGV4dCBpcyBhIGdvb2QgaWRlYSBvciBub3QuIFlvdSBjb3Vs ZCBldmVuIHRoaW5rIG9mIHNlbmRpbmcgYm90aCB0eXBlcyBvZiBBQ0tzLCBidXQgdGhhdCB3b3Vs ZCBicmluZyB0aGUgaW1wbGVtZW50YXRpb24gb3V0IG9mIFJGQzY1NTAuDQo+Pj4NCj4+PiBDaGVl cnMsDQo+Pj4gQ3NhYmENCj4+Pg0KPj4+IE9uIDAyLzEwLzE1IDE1OjA0LCBQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpIHdyb3RlOg0KPj4+PiBIZWxsbyBKb2FraW06DQo+Pj4+DQo+Pj4+IFdoYXQg SSByZWFkIGhlcmUgYm9pbHMgZG93biB0byBhIGxpbWl0ZWQgZGlmZnVzaW9uIGFsZ29yaXRobS4g V2UgdHJpZWQgdG8gYXZvaWQgdGhhdCBpbiBSUEwgYmVjYXVzZSBhbnkgbW92ZW1lbnQgd2l0aGlu IHRoZSBjb252ZXJnZW5jZSB3b3VsZCBjYXVzZSBhIGRlYWRsb2NrLiBJT1cgaWYgZXZlcnkgbm9k ZSB3YWl0cyBmb3IgKGFsbCBvZikgdGhlIHBhcmVudHMgdG8gYWNrLCB0aGVuIHRoaXMgcmVjdXJz aXZlbHkgdGFrZXMgeW91IHRvIHRoZSByb290LCBhbmQgaWYgYW55IG5vZGUgaW4gdGhlIGNoYWlu IG1vdmVzIG9yIGRpZXMsIHRoZSBkaWZmdXNpb24gd2lsbCBub3QgYmUgY29tcGxldGUuDQo+Pj4+ DQo+Pj4+IENoZWVycywNCj4+Pj4NCj4+Pj4gUGFzY2FsDQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvYWtpbSANCj4+Pj4+IEVyaWtzc29uDQo+Pj4+PiBTZW50 OiBqZXVkaSAxIG9jdG9icmUgMjAxNSAyMjoxMQ0KPj4+Pj4gVG86IFJvdXRpbmcgT3ZlciBMb3cg cG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDog UmU6IFtSb2xsXSBTZW1hbnRpY3Mgb2YgREFPIEFDSw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gT24g MDEgT2N0IDIwMTUsIGF0IDIxOjAzLCBDc2FiYSBLaXJhbHkgPGtpcmFseUBmYmsuZXU+IHdyb3Rl Og0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDMwLzA5LzE1IDE3OjU1LCBKb2Fr aW0gRXJpa3Nzb24gd3JvdGU6DQo+Pj4+Pj4+PiBPbiAzMCBTZXAgMjAxNSwgYXQgMDY6NDQsIENz YWJhIEtpcmFseSA8a2lyYWx5QGZiay5ldT4gd3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSGVs bG8gSm9ha2ltLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgaGF2ZSBhbHNvIHdvcmtlZCBvbiB0aGUg Q29udGlraSBEQU8tQUNLIGNvZGUsIGVuYWJsaW5nIEFDS3MsDQo+Pj4+PiBpbXBsZW1lbnRpbmcg Zml4ZXMgdG8gdGhlIERBT1NlcXVlbmNlIGhhbmRsaW5nLCBhbmQgbG9va2luZyBpbnRvIA0KPj4+ Pj4gbXVsdGlwbGUgdGFyZ2V0cy4NCj4+Pj4+Pj4gTmljZSwgSSBoYXZlIGEgUFIgb24gQ29udGlr aSBub3cgd2l0aCB3aGF0IHdlIGhhdmUgYmVlbiBkb2luZyB0byANCj4+Pj4+Pj4gZ2V0DQo+Pj4+ PiBDb250aWtpIFJQTCBtb3JlIHNjYWxhYmxlIChidXQgc3RpbGwgb25seSBzaW5nbGUgdGFyZ2V0 cyAvIHBhdGhzKS4NCj4+Pj4+Pj4+IFdoYXQgQ2VuayBpcyBzYXlpbmcgc291bmRzIGEgcmVhc29u YWJsZSBoYWNrLCBidXQgdGhlIHN0YW5kYXJkIA0KPj4+Pj4+Pj4gaXRzZWxmDQo+Pj4+PiBpcyBp biBteSBvcGluaW9uIGEgYml0IHVuZGVyc3BlY2lmaWVkIGZvciB0aGUgc2VtYW50aWNzIG9mIERB Ty1BQ0sgDQo+Pj4+PiBtZXNzYWdlcyBpbiBzZXZlcmFsIHdheXMuDQo+Pj4+Pj4+IFllcywgaXQg aXMgdW5kZXJzcGVjaWZpZWQuIFRoZXJlIGlzIG5lZWQgZm9yIGNsYXJpZmljYXRpb25zIGFuZCAN Cj4+Pj4+Pj4gbW9yZSBkZXRhaWxzDQo+Pj4+PiBvbiB0aGUgREFPIC8gREFPIEFDSyENCj4+Pj4+ Pj4+IE15IHByZWZlcnJlZCBzb2x1dGlvbiBmb3IgQUNLaW5nIERBTyBtZXNzYWdlcyB3aXRoIG11 bHRpcGxlIA0KPj4+Pj4+Pj4gdGFyZ2V0cw0KPj4+Pj4gd291bGQgYmUgdG8gaGF2ZSBzdXBwb3J0 IGZvciB0aGUgc2FtZSBzZW1hbnRpY3MgdGhhdCB5b3Ugd291bGQgDQo+Pj4+PiBoYXZlIGhhZCB3 aXRoIG9uZSBEQU8gbWVzc2FnZSBwZXIgVGFyZ2V0LCBpLmUuLCBJIHdvdWxkIHByZWZlciBhbiAN Cj4+Pj4+IG9wdGlvbiBmaWVsZCB0aGF0IGdpdmVzIGFuIGluZGl2aWR1YWwgc3RhdHVzIGZvciBl YWNoIFRhcmdldC4NCj4+Pj4+Pj4gWWVzLCBidXQgdGhhdCB3b3VsZCByZXF1aXJlIG1vcmUgbWVt b3J5IGluIHRoZSBzZW5kaW5nIG5vZGUgdG8gDQo+Pj4+Pj4+IGtlZXANCj4+Pj4+IHRyYWNrIG9m IHRoaW5ncyBvciBmdWxsIHNwZWNpZmljYXRpb24gb2YgdGhlIHRhcmdldCBpbiB0aGUgcmVzcG9u c2UuDQo+Pj4+Pj4+IEkgZ3Vlc3MgaXQgbWlnaHQgYmUgc29sdmVkIGJ5IGFsbG93aW5nIG11bHRp cGxlIERBTyBBQ0tzIGZvciB0aGUgDQo+Pj4+Pj4+IHNhbWUNCj4+Pj4+IERBTyBhbmQgdG8gaGF2 ZSB0aGUgVGFyZ2V0IG9wdGlvbnMgaW5jbHVkZWQgaW4gdGhlIERBTyBBQ0suDQo+Pj4+Pj4gVGhp cyBpcyBhIGNvbXByb21pc2UgdG8gY29uc2lkZXIgZm9yIHN1cmUuIElmIHlvdSBsb29rIGF0IG15 DQo+Pj4+PiBpbXBsZW1lbnRhdGlvbiwgeW91IGNhbiBzZWUgdGhhdCBJIHVzZSB0aGUgcm91dGlu ZyB0YWJsZSBlbnRyeSB0byANCj4+Pj4+IG1hdGNoIHRoZSBEQU8gQUNLLCBhbmQgSSBrZWVwIG9u bHkgREFPU2VxdWVuY2UgKFNFUSkgYXMgZXh0cmEgDQo+Pj4+PiBzdGF0ZS4gSSdtIG5vdCBzdXJl IGl0IHdvdWxkIHdvcmsgaW4gYWxsIGNhc2VzLCBidXQgaXQgZGlkIHdvcmsgDQo+Pj4+PiBmb3Ig dGhlIGNhc2UgSSBjb25zaWRlcmVkLiBJJ20ga2VlcGluZyBvbmx5IHRoZSBTRVEsIGFuZCBJIHRo aW5rIA0KPj4+Pj4gdGhpcyBpcyBhIG11c3QgaWYgeW91IGhhdmUgbm8gYWdncmVnYXRpb24sIGFu ZCB5b3Ugd2FudCB0byBtYXRjaCANCj4+Pj4+IGluIGNhc2UgeW91IGZvcndhcmQgbXVsdGlwbGUg REFPcyBiZWZvcmUgZ2V0dGluZyB0aGUgQUNLIG9yIHRpbWluZyANCj4+Pj4+IG91dCBvbiBpdC4g SW4gZmFjdCwgc2ltcGx5IGVuYWJsaW5nIEFDS3MgaW4gdGhlIG9yaWdpbmFsIGNvZGUgd2FzIA0K Pj4+Pj4gbWVzc2luZyB1cCB0aGUgbWF0Y2ggYmV0d2VlbiBEQU9zIGFuZCB0aGVpciBBQ0tzIGJl Y2F1c2UgaXQgd2Fzbid0IGV2ZW4ga2VlcGluZyB0cmFjayBvZiB0aGUgREFPIHNlcXVlbmNlIG51 bWJlcnMuDQo+Pj4+Pj4gSWYgeW91IGRvIGFnZ3JlZ2F0ZSBBQ0tzLCBvciB5b3UgaGF2ZSBtb3Jl IGNvbXBsZXggVGFyZ2V0K1RyYW5zaXQNCj4+Pj4+IHNjZW5hcmlvcywgdGhlIGdhbWUgY2hhbmdl cywgYW5kIEkgZG9uJ3Qga25vdyB3aGF0IHdvdWxkIGJlIHRoZSANCj4+Pj4+IGJhbGFuY2UgYmV0 d2VlbiBzdGF0ZSB5b3UgaGF2ZSB0byBrZWVwIGFueXdheSBhbmQgc3RhdGUgeW91IGtlZXAgDQo+ Pj4+PiBqdXN0IHRvIGJlIGFibGUgdG8gaW50ZXJwcmV0IGEgbGF0ZXIgQUNLIGNvcnJlY3RseS4g SSB0aGluayBpdCBpcyANCj4+Pj4+IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLCBzbyBteSBzdWdn ZXN0aW9uIHdvdWxkIGJlIGEgZmxhZyB0byANCj4+Pj4+IGluZGljYXRlIHdoZXRoZXIgeW91IHJl cXVlc3QgZnVsbCBBQ0sgKGJ1bXBpbmcgYmFjayBhbGwgVCtUIGluZm8gDQo+Pj4+PiBmb3IgcmVq ZWN0ZWQgZW50cmllcyBpbiB0aGUgREFPKSBvciBhIG11Y2ggc21hbGxlciBwYXJ0aWFsIEFDSyAN Cj4+Pj4+IHdpdGggU0VRIGFuZCBzaW1pbGFyIElEcyBvbmx5LiBUaGlzIGZsYWcgKGxldHMgY2Fs bCBpdCBGIGZvciBub3cpLCANCj4+Pj4+IGNvdWxkIGdvIHJpZ2h0IG5leHQgdG8gSy4gQXMgdGhl IERBTyBwcm9wYWdhdGVzLCBlYWNoIG5vZGUgY291bGQgDQo+Pj4+PiBzZXQgRiBiYXNlZCBvbiB3 aGV0aGVyIGl0IGlzIGFibGUgdG8gc3RvcmUgYW5kL29yIHJlcHJvZHVjZSBpbmZvIA0KPj4+Pj4g KEYgbm90DQo+Pj4+PiBzZXQpIG9yIGNob3NlIHRvIHJlbWFpbiBzdGF0ZWxlc3MgKHNldCBGICku IFRoaXMgd291bGQgZXhjbHVkZSBhZ2dyZWdhdGlvbiBpbiB0aGUgREFPLUFDSyBzZW50IGRvd24s IGJ1dCBzdGlsbCBhbGxvdyBmb3IgYWdncmVnYXRpb24gaW4gdGhlIERBTyBzZW50IHVwLg0KPj4+ Pj4+Pj4gVG8gZ2l2ZSBhbm90aGVyIGV4YW1wbGUgb2Ygc3VidGxlIHByb2JsZW1zIHdpdGggREFP LUFDSywgaXQgd2FzIA0KPj4+Pj4+Pj4gbm90DQo+Pj4+PiBjbGVhciB0byBtZSB3aGV0aGVyIEkg d2FudCBteSBpbXBsZW1lbnRhdGlvbiB0byBBQ0sgd2hlbiB0aGUgDQo+Pj4+PiBUYXJnZXQgaXMg YWRkZWQgdG8gdGhlIHJvdXRpbmcgdGFibGUsIG9yIG9ubHkgd2hlbiB0aGlzIG5vZGUgDQo+Pj4+ PiBpdHNlbGYgcmVjZWl2ZXMgYW4gQUNLIGZvciB0aGUgc2FtZSBUYXJnZXQgZnJvbSBpdHMgcGFy ZW50LiBCb3RoIA0KPj4+Pj4gbWFrZXMgc2Vuc2UsIHdpdGggdGhlIGZvcm1lciBnaXZpbmcgYSBx dWljayBvbmUtaG9wIEFDSywgd2hpbGUgdGhlIA0KPj4+Pj4gbGF0dGVyIHdvcmtzIGFzIGFuIGVu ZC10by1lbmQgQUNLLCBlbnN1cmluZyB0aGF0IHRoZSBwYXRoIGlzIA0KPj4+Pj4gYWN0dWFsbHkg YnVpbHQuIEJvdGggbG9vayBjb25mb3JtYW50IHRvIHRoZSBzdGFuZGFyZCwgYnV0IEkgDQo+Pj4+ PiBzdXBwb3NlIHRoZSBvcmlnaW5hbCBhdXRob3Igd2FzIHRoaW5raW5nIG9mIHRoZSBmb3JtZXIs IGFuZCBJIGNhbiANCj4+Pj4+IGVhc2lseSBzZWUgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBh cmlzaW5nIGJldHdlZW4gdHdvIGltcGxlbWVudGF0aW9ucyB1c2luZyBkaWZmZXJlbnQgc2VtYW50 aWNzLg0KPj4+Pj4+PiBXZSBkaWQgZ28gZm9yIHRoZSBlbmQtdG8tZW5kIEFDSyB0byBhY2hpZXZl IGJldHRlciBzY2FsYWJpbGl0eS4NCj4+Pj4+Pj4gVGhlcmUgaXMgdG8gbWUgbm8gcG9pbnQgaGF2 aW5nIGEgcm91dGUgdG8gdGhlIHBhcmVudCBpZiBpdCBpcyANCj4+Pj4+Pj4gbm90IHBvc3NpYmxl IHRvIGdldA0KPj4+Pj4gaXQgYWxsIHRoZSB3YXkgdG8gcm9vdC4gQnV0IEkgdG90YWxseSBhZ3Jl ZSAtIHRoaXMgaXMgbm90IG9idmlvdXMgDQo+Pj4+PiBmcm9tIHRoZSBSUEwgUkZDIGVpdGhlci4N Cj4+Pj4+PiBEbyB5b3UgbWVhbiBlbmQtdG8tZW5kIEFDSyBhcyBpbiBub24tc3RvcmluZywgb3Ig ZW5kLXRvLWVuZCBBQ0sgDQo+Pj4+Pj4gaW4gdGhlDQo+Pj4+PiBzZW5zZSB0aGF0IGl0IGlzIHN0 aWxsIGFkZHJlc3NlZCB0byB0aGUgbmV4dCBob3AgYnV0IHlvdSBkZWxheSBBQ0sgDQo+Pj4+PiB0 aWxsIHlvdSBrbm93IHlvdXIgcGFyZW50IChhbmQgYWxsIGl0cyBwYXJlbnRzKSBBQ0tlZD8NCj4+ Pj4+IEkgbWVhbiBlbmQtdG8tZW5kIGFzIGluIHdhaXRpbmcgZm9yIGFsbCB0aGUgcGFyZW50cyB0 byBBQ0sgc28gdGhhdCANCj4+Pj4+IGJlZm9yZSBBQ0tpbmcgaXQgaXMga25vd24gdGhhdCB0aGUg cm91dGUgaXMgcHJvcGVybHkgaW5zdGFsbGVkIHdoZXJlIGl0IG5lZWRzIHRvLg0KPj4+Pj4NCj4+ Pj4+Pj4gRG8geW91IGhhdmUgeW91ciBDb250aWtpIGNvZGUgc29tZXdoZXJlIGluIHRoZSBvcGVu LXNvdXJjZT8NCj4+Pj4+PiBJIGRpZCBzb21lIGNsZWFudXAgYW5kIHB1c2hlZCB0aGUgY2xlYW4g cGFydCBvZiB0aGUgY29kZSB0byBnaXRodWI6DQo+Pj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2Nz a2lyYWx5L2NvbnRpa2kvdHJlZS9EQU8tTkFDSw0KPj4+Pj4+IEl0IGlzIG5vdCB5ZXQgcmViYXNl ZCB0byB0aGUgbGF0ZXN0IG1hc3RlciwgYnV0IGl0IHNob3VsZCBhcHBseS4gDQo+Pj4+Pj4gSSBz dXBwb3NlDQo+Pj4+PiBkZXNjcmliaW5nIGl0IHdvdWxkIGJlIHRvbyBvZmYtdG9waWMgZm9yIHRo ZSBsaXN0Lg0KPj4+Pj4+IFRoZXJlIGlzIGFsc28gdGhlIG1vcmUgZXhwZXJpbWVudGFsIHBhcnQg b2YgdGhlIGNvZGUgaW4gYSBQUiwgaWYgaW50ZXJlc3RlZC4NCj4+Pj4+IE9rIC0gSeKAmWxsIHRh a2UgYSBsb29rIQ0KPj4+Pj4NCj4+Pj4+IEJUVzogV2UgaGF2ZSBkb25lIGEgZmV3IGRlcGxveW1l bnRzIHVzaW5nIG91ciBpbXBsZW1lbnRhdGlvbiB1c2luZyANCj4+Pj4+IFlhbnppIG5ldHdvcmtz IHByb2R1Y3RzIC0gdGFrZSBhIGxvb2sgYXQgdGhpcyB2aWRlbyB3aGVyZSAxMDAwIA0KPj4+Pj4g bm9kZXMgaXMgZGVwbG95ZWQgd2l0aCBDb250aWtpIFJQTCArIG91ciBmaXhlcyBhbmQgMjAgbmVp Z2hib3JzIA0KPj4+Pj4gYW5kIHJvdXRlcyBwZXIgbm9kZS4gSWYgd2l0aG91dCBvdXIgZml4ZXMg aXQgd291bGQgbm90IHdvcmsgc2luY2UgDQo+Pj4+PiBDb250aWtpIFJQTCBkaWQgbm90IGFsbG93 IHNjYWxpbmcgYmV5b25kIG51bWJlciBvZiBuZWlnaGJvcnMgYW5kIA0KPj4+Pj4gcm91dGVzIC8g bm9kZSB0aGF0IHdlbGwgYmVmb3JlIHRoZXNlIGZpeGVzLg0KPj4+Pj4NCj4+Pj4+IGh0dHA6Ly93 d3cueWFuemkuc2UvdmlkZW8uanNwP2lkPTcNCj4+Pj4+DQo+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ Pj4+PiDigJQgSm9ha2ltIEVyaWtzc29uDQo+Pj4+Pg0KPj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+ Pj4+PiBDc2FiYQ0KPj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4+IOKAlCBKb2FraW0NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+Pj4+IENzYWJhDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gT24gMjkvMDkvMTUgMjM6MDgsIENlbmsgR8O8bmRvZ2FuIHdyb3RlOg0KPj4+Pj4+ Pj4+IEhlbGxvIEpvYWtpbSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgcXVlc3Rpb24gYW5kIEkgYWxzbyBjb3VsZG4ndCBmaW5kIGFueSANCj4+Pj4+Pj4+PiBh bnN3ZXJzIGluDQo+Pj4+PiBSRkMgNjU1MC4NCj4+Pj4+Pj4+PiBIb3dldmVyLCBteSB0aG91Z2h0 cyBvbiB0aGlzIGFyZSBhcyBmb2xsb3dzOg0KPj4+Pj4+Pj4+IFNpbmNlIGEgc3ViLXNldCBvZiB0 aGUgYW5ub3VuY2VkIFJQTCB0YXJnZXRzIGNvdWxkIGhhdmUgYmVlbiANCj4+Pj4+Pj4+PiBhY2Nl cHRlZCBiZWZvcmUgZmlsbGluZyB1cCB0aGUgcm91dGluZyB0YWJsZSAoZS5nLiksIEkgd291bGQg DQo+Pj4+Pj4+Pj4gY2hvb3NlIGENCj4+Pj4+IHN0YXR1cyBjb2RlIGJldHdlZW4gMSBhbmQgMTI3 Lg0KPj4+Pj4+Pj4+IEkgd291bGQgZXhwZWN0IGEgbm9kZSB0byBjaG9vc2UgYW5vdGhlciBwYXJl bnQgaWYgYSBtb3JlIA0KPj4+Pj4+Pj4+IGFnZ3Jlc3NpdmUNCj4+Pj4+IHN0YXR1cyBjb2RlIGlz IHJlY2VpdmVkIChbMTI4LTI1NV0pLg0KPj4+Pj4+Pj4+IEJ1dCBhIGZ1bGwgcm91dGluZyB0YWJs ZSBjYW4gaGF2ZSBmcmVlIHNwYWNlIGFnYWluIHVudGlsIHRoZSANCj4+Pj4+Pj4+PiBuZXh0IG9y IGFueQ0KPj4+Pj4gc3Vic2VxdWVudCBEQU8gYXJyaXZlcyAuLg0KPj4+Pj4+Pj4+IHRoZXJlZm9y ZSBJIHByZWZlciBhICJtaWxkIHJlamVjdGlvbiIgd2l0aCBhIHN0YXR1cyBjb2RlIG9mIFsxLTEy N10uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUbyBnaXZlIHNvbWUgZmVlZGJhY2sgdG8gdGhlIG9y aWdpbmF0b3Igb2YgdGhlIERBTywgaXQgbWlnaHQgDQo+Pj4+Pj4+Pj4gYmUgc2Vuc2libGUgdG8g Y29weSB0aGUgcmVqZWN0ZWQgUlBMIFRhcmdldCBvcHRpb25zIGZyb20gdGhlIA0KPj4+Pj4+Pj4+ IGFmZmVjdGVkIERBTyB0byB0aGUgREFPLUFDSywgc28gdGhhdCB0aGUgb3JpZ2luYXRvciBpcyBm dWxseSANCj4+Pj4+Pj4+PiBhd2FyZSBvZiB3aGljaA0KPj4+Pj4gVGFyZ2V0IHByZWZpeGVzIGdv dCByZWplY3RlZCAoYW5kIHdoaWNoIG9uZXMgZ290IGFjY2VwdGVkLCBpbXBsaWNpdGx5KS4NCj4+ Pj4+Pj4+PiBJIHdvdWxkIGNob29zZSB0aGlzIG1ldGhvZCwgYmVjYXVzZSBpdCBkb2Vzbid0IHJl cXVpcmUgdGhlIA0KPj4+Pj4+Pj4+IG9yaWdpbmF0b3Igb2YgdGhlIERBTyB0byBzYXZlIGFueSBl eHRyYSBzdGF0ZSBhYm91dCB0aGUgREFPIA0KPj4+Pj4+Pj4+IGFuZCBpdHMNCj4+Pj4+IGNvbnRl bnRzLg0KPj4+Pj4+Pj4+IE5vbmV0aGVsZXNzLCBldmVyeXRoaW5nIEkgd3JvdGUgaXMgbm9uY29u Zm9ybSBhbmQgSSBhbSBhbHNvIA0KPj4+Pj4+Pj4+IGludGVyZXN0ZWQgaW4gdGhlIFJQTCBleHBl cnRzJyBvcGluaW9ucyBhbmQgc29sdXRpb25zLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmVzdCwN Cj4+Pj4+Pj4+PiBDZW5rDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAyOS4wOS4yMDE1IDIxOjQ0 LCBKb2FraW0gRXJpa3Nzb24gd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhlbGxvIEFsbCwNCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gSSBoYXZlIHNwZW5kIHF1aXRlIHNvbWUgdGltZSB0byBnZXQgYSBtb3Jl IHN0YWJsZSANCj4+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb24gb2YgREFPIGhhbmRsaW5nIGZvciBD b250aWtpIFJQTCBhbmQgSSBhbSANCj4+Pj4+Pj4+Pj4gY3VycmVudGx5IGxvb2tpbmcgaW50byBE QU8gYWdncmVnYXRpb24uIEJ1dCBJIHJlYWxpc2VkIHRoYXQgDQo+Pj4+Pj4+Pj4+IGl0IGlzIGZv ciBtZSBub3QgMTAwJSBjbGVhciB3aGF0IGEgbm9kZSB0aGF0IHJlY2VpdmVzIGEgREFPIA0KPj4+ Pj4+Pj4+PiB3aXRoIHNldmVyYWwgcHJlZml4ZXMgdG8gYmUgcmVnaXN0ZXJlZCBidXQgY2FuIG9u bHkgYWNjZXB0IGEgDQo+Pj4+Pj4+Pj4+IHN1Yi1zZXQgb2YgdGhlbS4gU2hvdWxkIGl0IGJlIGEN Cj4+Pj4+IERBT19OQUNLIGluIHRoaXMgY2FzZSBvciBpcyB0aGVyZSBhbnkgb3RoZXIgd2F5IHRv IGhhbmRsZSB0aGF0IGNhc2U/DQo+Pj4+Pj4+Pj4+IElmIGVhY2ggd291bGQgaGF2ZSBiZWVuIHNl bnQgc2VwYXJhdGVseSBpdCBpcyBvYnZpb3VzIHRoYXQgDQo+Pj4+Pj4+Pj4+IHRoZSByZWNlaXZp bmcgbm9kZSBjYW4gZG8gYSBOQUNLIHdoZW4gdGhlIHJvdXRpbmcgdGFibGUgaXMgDQo+Pj4+Pj4+ Pj4+IGZ1bGwgYW5kIHRoZXJlZm9yZSBpdCBpcyBwb3NzaWJsZSB0byBnZXQgZmluZS1ncmFpbmVk IA0KPj4+Pj4+Pj4+PiBhbnN3ZXJzLiBCdXQgd2l0aA0KPj4+Pj4gYWdncmVnYXRpb24gb2YgREFP cyB0aGlzIGlzIG5vdCB0aGUgY2FzZS4NCj4+Pj4+Pj4+Pj4gQW55IGlkZWFzPw0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+IOKAlCBKb2FraW0gRXJpa3Nz b24sIFNJQ1MNCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+Pj4+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4gUm9s bEBpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JvbGwNCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gUm9sbEBp ZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBSb2xsQGlldGYub3Jn DQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IFJvbGwgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+PiBS b2xsQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4+Pj4NCj4+Pj4NCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFJvbGwg bWFpbGluZyBsaXN0DQo+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcm9sbA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+PiBSb2xsQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5n IGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Mon Oct 19 02:37:55 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778D1A87AE for ; Mon, 19 Oct 2015 02:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ2YXd0VMmEC for ; Mon, 19 Oct 2015 02:37:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889CA1A87D1 for ; Mon, 19 Oct 2015 02:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1445247471; x=1446457071; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7jLeXU3is4PN/uFxnWHtDcEFLuBYbJ6VtrAHG2K2eF8=; b=FVrpTefehbZ31kRYjTzY0Sqnl/jfkxpRNQNlDtj3NsoRExx19qEl4eRF jSfElNVwFuCRJ7uOPuYMaY1yIFqlbZBLnGpSURcETBQZ6ylGWOqCcfe8n CgMQl5ycWbLi0jjFq0KamKIOtsdr+Ok50Ut3//oQRoSVW92icxT9Hv/CG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgCxuSRW/5JdJa1egzZUbwa9C3gBDYFaFwqFHl8CgSo4FAEBAQEBAQGBCoQtAQEBAwEBAQE3NBALAgEINhAnCyUCBBMIiCAIDcJcAQEBAQEBAQMBAQEBAQEdhneEfoUUhC4FliMBhRiHfYInmXcBHwEBQoQDcgGEYIEGAQEB X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="36966173" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 19 Oct 2015 09:37:32 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t9J9bWaW017282 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Oct 2015 09:37:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 04:37:15 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 04:37:15 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL-aware or not RPL-aware, that's the question Thread-Index: AQHRAolRpUMPLACE20y7AxKF3NeGDZ5uffpQ Date: Mon, 19 Oct 2015 09:37:01 +0000 Deferred-Delivery: Mon, 19 Oct 2015 09:36:37 +0000 Message-ID: References: <5617AB01.7060703@gmail.com> In-Reply-To: <5617AB01.7060703@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.163.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL-aware or not RPL-aware, that's the question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:37:53 -0000 Hello Cenk: =20 > I was hoping to find some answers to the question of how to know if a > target is within a RPL-domain or not. The rationale is that this knowledg= e is > needed to decide if an IP-in-IP encapsulation is needed or not for severa= l use > cases using the RPI header. > The last virtual interim meeting successfully identified these use cases = and > perpetuated them in the ether pad [1]. >=20 > AFAIK, there is no standard compliant way to announce routes in the RPL- > domain as routes being established through RPL DAOs or by other means. True, because for the base RPL, the RPL domain is a stub and each participa= ting node is RPL aware. At the call we were talking about non RPL hosts attached to RP routers.=20 This design is much wanted but not done yet. > I guess this information could be propagated using one of the Reserved1 > flags form the Prefix Information Option, or by using a specific descript= ior in > the RPL Descriptor Option (?). >=20 I'm not sure I follow you here. RPL does not send routes down the DODAG, but rather advertise routes that i= s reachable by the root; Note that this is done with a RIO not a PIO. The descriptor is for route tagging; it is a complement to a route but not = a protocol vehicle. > But such kind of propagation would still fail for traffic flows from a RP= L- > aware node to a common RPL parent and down to an arbitrary node (no > matter if RPL-aware or not), because the source node has no information > about the state of that arbitrary node. > Does anyone know how to handle this case? We really have to design for it. New stuff. Could be based on ICMP errors. Cheers Pascal > Best, > Cenk >=20 > [1] http://etherpad.tools.ietf.org:9000/p/ROLL-Interim_Meeting_-09-29- > 2015 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Oct 19 03:29:38 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24E1A88C4 for ; Mon, 19 Oct 2015 03:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYkGgL4UvP4E for ; Mon, 19 Oct 2015 03:29:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8810B1A88CF for ; Mon, 19 Oct 2015 03:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14830; q=dns/txt; s=iport; t=1445250574; x=1446460174; h=from:to:subject:date:message-id:mime-version; bh=q2kvluoSv0vUh2vHt3BLxnrTWoYnEYMXeIaLOwnztBQ=; b=aSRDP81pFHdJS1fLrOxde+KH/+m0FWoocfM0xDaMhaBuAmPnMJJ9L5/M i0kIPK38UUO8AQrQIW/Qo8bEO054nweVvQNmjivpBrG0eLN9o1QAH8bcn IvcU1dZbfGn835A0dVky/mVhMobeDXumbpjxbkQUZmIh4mzw3QzQFs6bf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQBExSRW/4QNJK1egmlNVG8GvgcBDYFaIYV9gS84FAEBAQEBAQGBCoQ0LV4BgQAmAQQbiCgNoCWiRAEBAQEBBQEBAQEBAQEYBIZ3igeEOQWSWoNJAY0VgV+EPJYDAR8BAUKCER2BVXIBhGCBBgEBAQ X-IronPort-AV: E=Sophos; i="5.17,701,1437436800"; d="scan'208,217"; a="36949891" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 19 Oct 2015 10:29:33 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t9JATX3x000699 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Oct 2015 10:29:33 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 05:29:16 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 05:29:15 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: DAO projection Thread-Index: AdEKV1jSce6uaagDR7CSIK0Czg97Og== Date: Mon, 19 Oct 2015 10:29:05 +0000 Deferred-Delivery: Mon, 19 Oct 2015 10:28:37 +0000 Message-ID: <7edf9ea4a75d4051a6779e4c16304cce@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.163.99] Content-Type: multipart/alternative; boundary="_000_7edf9ea4a75d4051a6779e4c16304cceXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] DAO projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 10:29:37 -0000 --_000_7edf9ea4a75d4051a6779e4c16304cceXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: At the last IETF, I presented the concept of DAO projection, that enables a= controlled amount of stateful routing in a general non storing mode. https://www.ietf.org/id/draft-thubert-roll-dao-projection-00.txt The draft enables loose source routing for long paths, eg: ------+--------- | Internet | +-----+ | | Border Router | | (RPL Root) +-----+ | ^ | | | DAO | ACK | o o o o | | | Loose o o o o o o o o o | ^ | Source o o o o o o o o o o | | DAO | Route o o o o o o o o o | ^ | o o o o o o o o v | DAO v o o o o LLN It also enables the root to work with (or as) a PCE and project optimized r= outes in the network which could improve the operation whether the network = is using storing or non-storing. ------+--------- | Internet | +-----+ | | Border Router | | (RPL Root) +-----+ | o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o>>o>>>o>>o>>>o o o o o o o o LLN We did not have much discussion on this topic since the IETF. So in prepara= tion of Yokohama, I'd like to sense interest in that topic. Continue, or dr= op? Please jump in! Pascal --_000_7edf9ea4a75d4051a6779e4c16304cceXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

At the last IETF, I presented the concept of DAO = projection, that enables a controlled amount of stateful routing in a gener= al non storing mode.

https://www.ietf.org/id/draft-thubert-roll-dao-= projection-00.txt

 

The draft enables loose source routing for long p= aths, eg:

 

 <= /o:p>

  =             ------&#= 43;---------

  =             &nb= sp;     |       &nbs= p;  Internet

  =             &nb= sp;     |

  =             &nb= sp;  +-----+

  =             &nb= sp;  |     | Border Router

  =             &nb= sp;  |     |  (RPL Root)

  =             &nb= sp;  +-----+        &n= bsp;            = ; |     ^        |

  =             &nb= sp;     |       &nbs= p;            &= nbsp;    | DAO | ACK    |

  =             o &= nbsp;  o   o    o    &nbs= p;            | = ;    |        | Loose

  =         o o   o  o &= nbsp; o  o  o o   o      =     |  ^        = ;   | Source

  =        o  o o  o o   = ; o   o   o  o  o    &nbs= p;  |  | DAO       | Route

  =        o   o    o&nb= sp; o     o  o    o  o  o=     | ^         = ;   |

  =       o  o   o  o   = o         o   o o &n= bsp;     v | DAO      &nb= sp; v

  =       o       &= nbsp;  o          &n= bsp;  o     o

  =             &nb= sp;           LLN

 

 

It also enables the root to work with (or as) a P= CE and project optimized routes in the network which could improve the oper= ation whether the network is using storing or non-storing.

 

 <= /o:p>

  =             ------&#= 43;---------

  =             &nb= sp;     |       &nbs= p;  Internet

  =             &nb= sp;     |

  =             &nb= sp;  +-----+

  =             &nb= sp;  |     | Border Router

  =             &nb= sp;  |     |  (RPL Root)

  =             &nb= sp;  +-----+        &n= bsp;           

  =             &nb= sp;     |       = ;            

  =             o&n= bsp;   o   o    o    = ;           

  =         o o   o  o&n= bsp;  o  o  o o   o     &= nbsp;   

  =        o  o o  o o  =   o   o   o  o  o    = ; 

  =        o   o   = o  o     o  o    o  o&nb= sp; o  

  =       o>>o>>>o>>o>>= ;>o         o   o o&nb= sp;     

  =       o      &n= bsp;   o         &nb= sp;   o     o

  =             &nb= sp;           LLN

 

 

 

We did not have much discussion on this topic sin= ce the IETF. So in preparation of Yokohama, I’d like to sense interes= t in that topic. Continue, or drop?

 

Please jump in!

 

Pascal

--_000_7edf9ea4a75d4051a6779e4c16304cceXCHRCD001ciscocom_-- From nobody Mon Oct 19 04:15:05 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0481A896B for ; Mon, 19 Oct 2015 04:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn6a6wCd_AFD for ; Mon, 19 Oct 2015 04:15:02 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B73A1A896A for ; Mon, 19 Oct 2015 04:15:02 -0700 (PDT) Received: by lbbes7 with SMTP id es7so51521533lbb.2 for ; Mon, 19 Oct 2015 04:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=wwFhJUav0K5r3Sa4GDBMqXZctwJtnhmmcmf8Q5KXcP8=; b=nwp/ASsIzg54HXT0Fu2tffYPlDaIzaIPBlOAYlrsJfwPdNmUk+NzgM/no+Dzp67zTH MENTO3SRiUUss+l1Mg4dMDGnQxQowlTxcfxKRTuvSmWXOAq9ZdnBm6b2jCAgywdwSDAG DQEvpQ+tAQPSTj53X1QwySuunEQe00vScvfpdRJNzlvVY7Lgjdxhl8GElV5ln+nXK/b8 SSDW7KSwPioIwNsxDkGbeZ0CilIppEwVD7bURtg3PfNd5SgQguN1/ijH5Fmht58G4LtW 48QWCrAK1yR+YThc8J5q7pgHmBqak96FvycnmgrkHprl5/xCilRroa7ga0SVoL0DOIMz HF3A== X-Received: by 10.112.125.231 with SMTP id mt7mr14049170lbb.87.1445253300412; Mon, 19 Oct 2015 04:15:00 -0700 (PDT) Received: from [10.92.124.3] (z5c7c.pia.fu-berlin.de. [87.77.92.124]) by smtp.googlemail.com with ESMTPSA id jk6sm5275194lbc.36.2015.10.19.04.14.59 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Oct 2015 04:14:59 -0700 (PDT) To: roll@ietf.org References: <5617AB01.7060703@gmail.com> From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= Message-ID: <5624D0B2.2030803@gmail.com> Date: Mon, 19 Oct 2015 13:14:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] RPL-aware or not RPL-aware, that's the question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 11:15:04 -0000 Hello Pascal, thank you very much for your response. On 19.10.2015 11:37, Pascal Thubert (pthubert) wrote: > Hello Cenk: > >> I was hoping to find some answers to the question of how to know if a >> target is within a RPL-domain or not. The rationale is that this knowledge is >> needed to decide if an IP-in-IP encapsulation is needed or not for several use >> cases using the RPI header. >> The last virtual interim meeting successfully identified these use cases and >> perpetuated them in the ether pad [1]. >> >> AFAIK, there is no standard compliant way to announce routes in the RPL- >> domain as routes being established through RPL DAOs or by other means. > True, because for the base RPL, the RPL domain is a stub and each participating node is RPL aware. > At the call we were talking about non RPL hosts attached to RP routers. > This design is much wanted but not done yet. > >> I guess this information could be propagated using one of the Reserved1 >> flags form the Prefix Information Option, or by using a specific descriptior in >> the RPL Descriptor Option (?). >> > I'm not sure I follow you here. > > RPL does not send routes down the DODAG, but rather advertise routes that is reachable by the root; > Note that this is done with a RIO not a PIO. > > The descriptor is for route tagging; it is a complement to a route but not a protocol vehicle. What I was actually aiming for was the `E` flag in the Transit Option within DAOs, that marks routes as external routes when they weren't set-up by RPL. This information is propagated upwards the DAG and hence a parent would be able to decide if the destination is RPL-aware or not. I completely overlooked this flag and tried to simulate this behaviour with the descriptor field. My bad.. (Mentioning the prefix information flags was also complete non-sense). >> But such kind of propagation would still fail for traffic flows from a RPL- >> aware node to a common RPL parent and down to an arbitrary node (no >> matter if RPL-aware or not), because the source node has no information >> about the state of that arbitrary node. >> Does anyone know how to handle this case? > We really have to design for it. New stuff. Could be based on ICMP errors. I assume such an effort would take place within this WG/mailing list? Best, Cenk > > Cheers > > Pascal > >> Best, >> Cenk >> >> [1] http://etherpad.tools.ietf.org:9000/p/ROLL-Interim_Meeting_-09-29- >> 2015 >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Oct 19 04:47:05 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9951A8BBF for ; Mon, 19 Oct 2015 04:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm8odICKQA29 for ; Mon, 19 Oct 2015 04:47:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315DF1A8AEB for ; Mon, 19 Oct 2015 04:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3258; q=dns/txt; s=iport; t=1445255221; x=1446464821; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=j5OAgF8pCXT1/SVJ98WYoocEGGBLBREB91fz5aKwIPQ=; b=dk0Kf+esJl8T66w1ythy+4EggFBj4IWMNdPSSh2/Gg8NDpI1vICSiZb9 MJI7Cf/ef0bgA/PI3PalolYYX492FwViQnpHMpCkzCNJRa582mC4z/t1m HkKpDz0KDlHUQrXAmuqRaACDQ41DUD1GWd2Bb98MUE6MTmCbFUNnyuwQD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BEAgDp1iRW/5pdJa1egzZUb70WeAENgVoXCoUeXwKBNDgUAQEBAQEBAYEKhC0BAQEDAQEBAWsQCwIBCBguIQYLJQIEE4gbAwoIDb15DYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3ghCCboJQggouDIMagRQFjUuIWAGFGIYPgXWBWEiSLoNbg24BHwEBQoQDcgGFZgEBAQ X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="38807223" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 19 Oct 2015 11:47:00 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9JBkv0K007554 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Oct 2015 11:46:57 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 06:46:39 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 06:46:39 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL-aware or not RPL-aware, that's the question Thread-Index: AQHRCl9iZ1FICtfjK0e+K6lQ9asWZ55ysuP2 Date: Mon, 19 Oct 2015 11:46:39 +0000 Message-ID: <88E01550-BD19-4C85-AFEC-B4A41279F04D@cisco.com> References: <5617AB01.7060703@gmail.com> , <5624D0B2.2030803@gmail.com> In-Reply-To: <5624D0B2.2030803@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL-aware or not RPL-aware, that's the question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 11:47:04 -0000 Yes, enabling non RPL aware leaf is important and should happen here and so= on! Pascal > Le 19 oct. 2015 =E0 13:14, Cenk G=FCndogan a =E9crit= : >=20 > Hello Pascal, >=20 > thank you very much for your response. >=20 >> On 19.10.2015 11:37, Pascal Thubert (pthubert) wrote: >> Hello Cenk: >> =20 >>> I was hoping to find some answers to the question of how to know if a >>> target is within a RPL-domain or not. The rationale is that this knowle= dge is >>> needed to decide if an IP-in-IP encapsulation is needed or not for seve= ral use >>> cases using the RPI header. >>> The last virtual interim meeting successfully identified these use case= s and >>> perpetuated them in the ether pad [1]. >>>=20 >>> AFAIK, there is no standard compliant way to announce routes in the RPL= - >>> domain as routes being established through RPL DAOs or by other means. >> True, because for the base RPL, the RPL domain is a stub and each partic= ipating node is RPL aware. >> At the call we were talking about non RPL hosts attached to RP routers. >> This design is much wanted but not done yet. >>=20 >>> I guess this information could be propagated using one of the Reserved1 >>> flags form the Prefix Information Option, or by using a specific descri= ptior in >>> the RPL Descriptor Option (?). >> I'm not sure I follow you here. >>=20 >> RPL does not send routes down the DODAG, but rather advertise routes tha= t is reachable by the root; >> Note that this is done with a RIO not a PIO. >>=20 >> The descriptor is for route tagging; it is a complement to a route but n= ot a protocol vehicle. >=20 > What I was actually aiming for was the `E` flag in the Transit Option wit= hin DAOs, that marks > routes as external routes when they weren't set-up by RPL. This informati= on is propagated upwards > the DAG and hence a parent would be able to decide if the destination is = RPL-aware or not. > I completely overlooked this flag and tried to simulate this behaviour wi= th the descriptor field. My bad.. > (Mentioning the prefix information flags was also complete non-sense). >=20 >>> But such kind of propagation would still fail for traffic flows from a = RPL- >>> aware node to a common RPL parent and down to an arbitrary node (no >>> matter if RPL-aware or not), because the source node has no information >>> about the state of that arbitrary node. >>> Does anyone know how to handle this case? >> We really have to design for it. New stuff. Could be based on ICMP error= s. > I assume such an effort would take place within this WG/mailing list? >=20 > Best, > Cenk >=20 >>=20 >> Cheers >>=20 >> Pascal >>=20 >>> Best, >>> Cenk >>>=20 >>> [1] http://etherpad.tools.ietf.org:9000/p/ROLL-Interim_Meeting_-09-29- >>> 2015 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Oct 19 11:18:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05F1B2B50; Mon, 19 Oct 2015 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuTyV15zsdNS; Mon, 19 Oct 2015 11:18:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F1A1B2AE7; Mon, 19 Oct 2015 11:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17509; q=dns/txt; s=iport; t=1445278721; x=1446488321; h=from:to:cc:subject:date:message-id:mime-version; bh=QmhsEHOmpfyadDWyYDq1k4igb2GayXB+ZkFe6B3nONI=; b=X03ydgi4miJ8h2pwFuRT5enfgG0j7HF0eWeTtRf2pKpCqtXp998+y4jc YTQ5c4L7v6OhyYfsZeeXsQc4VFlqb9Zvc/tgsPeZdF43/WUM6Q3aO4bzI 4NhZoGaQ/pTjhmN9kjLZ3SUE2uzdRrpEaW/D25TgLwBWI3aKodS/gY2PP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9AQCvMiVW/5ldJa1egmlNVG8GvgkBDYFaIYV9AoE8OBQBAQEBAQEBgQqELQEBAQQtTBIBGQQBASg5FAkJAQQOBQiIKA3EOQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhneJPEsEBoQvBZJag0kBjRWBX4Q8lgMBHwEBQoIRHYFVcgGEYIEGAQEB X-IronPort-AV: E=Sophos; i="5.17,703,1437436800"; d="scan'208,217"; a="38974916" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 19 Oct 2015 18:18:40 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9JIIePu027042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 18:18:40 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 13:18:22 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 13:18:22 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: draft-thubert-roll-dao-projection Thread-Index: AdEKmkpsr2DNH7EVRxWFejZGqsstFg== Date: Mon, 19 Oct 2015 18:18:14 +0000 Deferred-Delivery: Mon, 19 Oct 2015 18:17:36 +0000 Message-ID: <77f94ada924046b7b9ef2325f3a102fd@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_77f94ada924046b7b9ef2325f3a102fdXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: [Roll] draft-thubert-roll-dao-projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:18:45 -0000 --_000_77f94ada924046b7b9ef2325f3a102fdXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Being optimistic I published a refresh of the draft tough we did not get a = lot of discussion so far. https://www.ietf.org/id/draft-thubert-roll-dao-projection-01.txt The new version adds the capability by the PCE to add routes in a RPL netwo= rk. This may be useful for 6TiSCH when the PCE does not install tracks but simp= ly adds IPv6 routes for which OTF/6top will adapt the bandwidth. Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: lundi 19 octobre 2015 12:29 To: Routing Over Low power and Lossy networks Subject: [Roll] DAO projection Dear all: At the last IETF, I presented the concept of DAO projection, that enables a= controlled amount of stateful routing in a general non storing mode. https://www.ietf.org/id/draft-thubert-roll-dao-projection-00.txt The draft enables loose source routing for long paths, eg: ------+--------- | Internet | +-----+ | | Border Router | | (RPL Root) +-----+ | ^ | | | DAO | ACK | o o o o | | | Loose o o o o o o o o o | ^ | Source o o o o o o o o o o | | DAO | Route o o o o o o o o o | ^ | o o o o o o o o v | DAO v o o o o LLN It also enables the root to work with (or as) a PCE and project optimized r= outes in the network which could improve the operation whether the network = is using storing or non-storing. ------+--------- | Internet | +-----+ | | Border Router | | (RPL Root) +-----+ | o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o>>o>>>o>>o>>>o o o o o o o o LLN We did not have much discussion on this topic since the IETF. So in prepara= tion of Yokohama, I'd like to sense interest in that topic. Continue, or dr= op? Please jump in! Pascal --_000_77f94ada924046b7b9ef2325f3a102fdXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Being optimistic I pub= lished a refresh of the draft tough we did not get a lot of discussion so f= ar.

https://www.ietf.= org/id/draft-thubert-roll-dao-projection-01.txt

 = ;

The new version adds t= he capability by the PCE to add routes in a RPL network.<= /p>

This may be useful for= 6TiSCH when the PCE does not install tracks but simply adds IPv6 routes fo= r which OTF/6top will adapt the bandwidth.

 

Cheers,

 = ;

Pascal

 

From: Roll [mailto:roll-bounces@ietf.org] = On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 19 octobre 2015 12:29
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] DAO projection

 

Dear all:

 

At the last IETF, I presented the concept of DAO = projection, that enables a controlled amount of stateful routing in a gener= al non storing mode.

https://www.ietf.org/id/draft-thubert-roll-dao-= projection-00.txt

 

The draft enables loose source routing for long p= aths, eg:

 

 <= /o:p>

  =             ------&#= 43;---------

  =             &nb= sp;     |       &nbs= p;  Internet

  =             &nb= sp;     |

  =             &nb= sp;  +-----+

  =             &nb= sp;  |     | Border Router

  =             &nb= sp;  |     |  (RPL Root)

  =             &nb= sp;  +-----+        &n= bsp;            = ; |     ^        |

  =             &nb= sp;     |       &nbs= p;            &= nbsp;    | DAO | ACK    |

  =             o &= nbsp;  o   o    o    &nbs= p;            | = ;    |        | Loose

  =         o o   o  o &= nbsp; o  o  o o   o      =     |  ^        = ;   | Source

  =        o  o o  o o   = ; o   o   o  o  o    &nbs= p;  |  | DAO       | Route

  =        o   o    o&nb= sp; o     o  o    o  o  o=     | ^         = ;   |

  =       o  o   o  o   = o         o   o o &n= bsp;     v | DAO      &nb= sp; v

  =       o       &= nbsp;  o          &n= bsp;  o     o

  =             &nb= sp;           LLN

 

 

It also enables the root to work with (or as) a P= CE and project optimized routes in the network which could improve the oper= ation whether the network is using storing or non-storing.

 

 <= /o:p>

  =             ------&#= 43;---------

  =             &nb= sp;     |       &nbs= p;  Internet

  =             &nb= sp;     |

  =             &nb= sp;  +-----+

  =             &nb= sp;  |     | Border Router

  =             &nb= sp;  |     |  (RPL Root)

  =             &nb= sp;  +-----+        &n= bsp;           

  =             &nb= sp;     |       = ;            

  =             o&n= bsp;   o   o    o    = ;           

  =         o o   o  o&n= bsp;  o  o  o o   o     &= nbsp;   

  =        o  o o  o o  =   o   o   o  o  o    = ; 

  =        o   o   = o  o     o  o    o  o&nb= sp; o  

  =       o>>o>>>o>>o>>= ;>o         o   o o&nb= sp;     

  =       o      &n= bsp;   o         &nb= sp;   o     o

  =             &nb= sp;           LLN

 

 

 

We did not have much discussion on this topic sin= ce the IETF. So in preparation of Yokohama, I’d like to sense interes= t in that topic. Continue, or drop?

 

Please jump in!

 

Pascal

--_000_77f94ada924046b7b9ef2325f3a102fdXCHRCD001ciscocom_-- From nobody Tue Oct 27 01:14:38 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BF51B37D1 for ; Tue, 27 Oct 2015 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zNOIEXMtC-9 for ; Tue, 27 Oct 2015 01:14:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982F51B37CC for ; Tue, 27 Oct 2015 01:14:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDD03582; Tue, 27 Oct 2015 08:14:16 +0000 (GMT) Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Oct 2015 08:14:14 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.53]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0235.001; Tue, 27 Oct 2015 16:13:46 +0800 From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] DIO compression option Thread-Index: AdD23JVMqzl6YbyQR+67lzbuc7ttTv//14aAgAC/BAD/zTnE0A== Date: Tue, 27 Oct 2015 08:13:46 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5C501EE5@szxeml558-mbs.china.huawei.com> References: <56046359.4070202@gmail.com> <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> In-Reply-To: <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.215.85] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5C501EE5szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 08:14:26 -0000 --_000_982B626E107E334DBE601D979F31785C5C501EE5szxeml558mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHF1ZXN0aW9uIGlzIGFib3V0IG5ldHdvcmstd2lkZSBkaXNzZW1pbmF0aW9uIG9mIGlu Zm9ybWF0aW9uLCB0aGVuIHRoZXJlIGFyZSBvdGhlciBjYW5kaWRhdGUgaW5mb3JtYXRpb24gYXMg d2VsbC4NCkZvciBlLmcuIHRoZXJlIGlzIG5vIGdvb2Qgd2F5ICBvZiBkaXNzZW1pbmF0aW5nIGNv cmUtcmQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1yZXNvdXJj ZS1kaXJlY3RvcnktMDU+IGFkZHJlc3MgaW5mb3JtYXRpb24gaW4gbXVsdGlob3AgTExOcyAocGxl YXNlIGNvcnJlY3QgbWUgaWYgd3JvbmcpLg0KVGhlIGNvcmUtcmQgUkZDIG1lbnRpb25zIGRpc2Nv dmVyeSBwcm9jZWR1cmVzIHdoaWNoIGFyZSBub3Qgd2VsbC1zdWl0ZWQgZm9yIExMTnMgKGZvciBl LmcuIGRyYWZ0IHNlY3Rpb24gNS4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5LTA1I3NlY3Rpb24tNS4xPiBzdWdnZXN0cyB1c2Ug b2YgbXVsdGljYXN0IHF1ZXJ5IHRvIGZldGNoIHRoZSBSRCBkZXRhaWxzKS4NCkl0IHdvdWxkIGJl IG5pY2UgdG8gaGF2ZSBESU8gb3B0aW9ucyB0byBkaXNzZW1pbmF0ZSBzdWNoIGluZm9ybWF0aW9u IGluIGEgY29udHJvbGxlZCB3YXkgKHN1Y2ggYXMgdGhlIHVzZSBvZiBESVMgdG8gcmVxdWVzdCBv cHRpb25zIGFzIFBhc2NhbCBzdWdnZXN0ZWQpLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGNvcmUtcmQg ZXhhbXBsZSBoZXJlIHNlcnZlcyBqdXN0IGFzIGEgcmVmZXJlbmNlIGZvciBzb21ldGhpbmcgd2hp Y2ggcmVxdWlyZXMgbmV0d29yay13aWRlIGRpc3NlbWluYXRpb24uDQoNClRodXMgIGltaG8sIHJh dGhlciB0aGFuIGhhdmluZyBhIGRyYWZ0IHNwZWNpZmljIHRvIERJTyA2Q08gZGlzc2VtaW5hdGlv biBpdCBjYW4gYmUgZ2VuZXJhbGl6ZWQgdG8gc29tZXRoaW5nIGxpa2Ug4oCcUlBMIE9wdGlvbnMg Zm9yIE5ldHdvcmstd2lkZSBkaXNzZW1pbmF0aW9uIOKApiDigJwgYW5kIGluY2x1ZGUgYWxsIChl dmVudHVhbGx5IGJ1aWxkIG9uIHRvIGl0KSAgdGhlIGRpZmZlcmVudCBvcHRpb25zIHBvc3NpYmxl Lg0KDQpDaGVlcnMsDQpSYWh1bA0KDQoNCkZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTZW50OiAy NSBTZXB0ZW1iZXIgMjAxNSBQTSAwNDoyMA0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5k IExvc3N5IG5ldHdvcmtzDQpTdWJqZWN0OiBSZTogW1JvbGxdIERJTyBjb21wcmVzc2lvbiBvcHRp b24NCg0KSGVsbG8gQ2Vuaw0KDQpUaGUgNlRpU0NIIGFyY2hpdGVjdHVyZSBpcyB0aGUgZmlyc3Qg SUVURiBlZmZvcnQgdGhhdCBjb21iaW5lcyBSUEwgYW5kIDZMb1dQQU4gTkQgYW5kIHN1Z2dlc3Rz IGEgd2F5IG9mIHB1dHRpbmcgdGhlbSB0b2dldGhlci4gVGhlIGVmZm9ydCBpcyBub3QgY29tcGxl dGUgYnV0IGl0IHJhaXNlcyB0aGF0IHNvcnQgb2YgY29leGlzdGVuY2UgcHJvYmxlbS4NCg0KT25l IG9mIHRoZSBjb25jbHVzaW9ucyBpcyB0aGF0IHRoZSA2QkJSIGFuZCB0aGUgUlBMIHJvb3Qgc2hv dWxkIGJlIGNvbGxvY2F0ZWQgc28gdGhhdCBhIHJvb3QgZ2V0cyBhIGRldmljZSB1bmlxdWUgSUQg KGZyb20gNkxvV1BBTiBORCkgYW5kIGEgc2VxdWVuY2UgY291bnRlciAoZnJvbSBSUEwpIHNpbmNl IGluIHByYWN0aWNlIGJvdGggYXJlIG5lZWRlZCBmb3IgdGhlIGJhY2tib25lIHJvdXRlciBvcGVy YXRpb24uIFRoZSBhcmNoaXRlY3R1cmUgYWxzbyBzdWdnZXN0cyB0aGF0IFJQTCBEQU8gc2VxdWVu Y2UgY291bnRlciBzaG91bGQgYmUgdXNlZCBhcyBUSUQgaW4gYW4gZXh0ZW5kZWQgQVJPIG9wdGlv bi4NCg0KVGhpcyBjb25jbHVzaW9uIG1hdGNoZXMgeW91cnMgdGhhdCBldmVuIHRob3VnaCB0aGUg MiBwcm90b2NvbHMgYXJlIGRlc2lnbmVkIHRvIHN1cnZpdmUgc3RhbmQgYWxvbmUsIHNvbWUgc2lt cGxpZmljYXRpb25zIGFuZCBwYWlyaW5ncyBhcmUgbmVlZGVkIHdoZW4gdGhleSBjb2V4aXN0Lg0K DQpBQlJPIGlzIG5vdCB0aGUgb25seSBvbmUuIFRoZSBESU8gZG9lcyBub3QgcHJvdmlkZSB0aGUg cm91dGVyIFNMTEEgZm9yIGluc3RhbmNlLCBzbyB0aGUgUkEgaXMgc3RpbGwgbmVlZGVkIGZvciB0 aGF0IGFzIHdlbGwuDQoNCknigJlsbCBzdXBwb3J0LCBhbmQgZXZlbiBjb250cmlidXRlIGlmIG5l ZWRlZCwgdG8gd29yayBhdCBST0xMIHRoYXQgYWxsb3dzIEFCUk8sIFNMTEFPLCBNVFVPIGFuZCA2 Q08gaW4gRElPcy4gVGhlIHdvcmsgbWF5IGltcGFjdCB0aGUgRElTIHRoYXQgY2FuIGJlIHVzZWQg dG8gcmVxdWVzdCBzb21lIG9wdGlvbnMgdGhhdCBkbyBub3QgbmVlZCB0byBiZSBjYXJyaWVkIGlu IGFsbCBESU9zIGluIGEgZmFzaGlvbiBzaW1pbGFyIHRvIHRoZSBET0RBRyBDb25maWd1cmF0aW9u IG9wdGlvbi4gSXQgbWF5IGFsc28gZGlzY3VzcyBpbiBtb3JlIGRldGFpbHMgaG93IERJT3MgYXJl IHNlbnQgb24gY29uc3RyYWluZWQgbWF4aW11bSBmcmFtZSBzaXplIHdoZW4gbXVsdGlwbGUgb3B0 aW9ucyBhcmUgbmVlZGVkLg0KDQpRdWVzdGlvbiB0byB0aGUgY2hhaXJzOiBpcyB0aGF0IHdvcmsg d2l0aGluIFdIIGNoYXJ0ZXIgYm91bmRhcmllcz8NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJv bTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENlbmsg R8O8bmRvZ2FuDQpTZW50OiBqZXVkaSAyNCBzZXB0ZW1icmUgMjAxNSAyMjo1Ng0KVG86IHJvbGxA aWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxdIERJTyBj b21wcmVzc2lvbiBvcHRpb24NCg0KSGVsbG8gQ2Fyc3RlbiwgUGFzY2FsLCBSYW5keSwgKg0KDQpJ IGxpa2UgdGhlIGlkZWEgb2YgaGF2aW5nIHRoZSA2Q08gaW5jbHVkZWQgaW50byBSUEwsIHNpbXBs eSBiZWNhdXNlIGl0IGFscmVhZHkgaW5jbHVkZXMgdGhlIFBJTw0KYW5kIHRoZXJlIGlzIG5vIFJQ TC1pc2ggd2F5IHRvIHRhZyBhbnkgcHJlZml4IGluZm9ybWF0aW9uIHdpdGggY29udGV4dCBpZGVu dGlmaWVycyBpbiA2TG9XUEFOcy4NCkhlbmNlLCBhbmQgdGhhdCBpcyBqdXN0IG15IG9waW5pb24s IGl0IGlzIG5vdCBkZXNpcmVkLCBidXQgYSBuZWNlc3NpdHkgdG8gYWRkIHRoZSA2Q08gdG8gUlBM J3MNCmtub3duIG9wdGlvbnMgbGlzdC4NCg0KQWxzbzogUkZDIDY3NzUjMS40IGNsZWFybHkgc3Rh dGVzIHRoYXQgaW4gb3JkZXIgdG8gc3Vic3RpdHV0ZSBtdWx0aWhvcCBwcmVmaXggZGlzdHJpYnV0 aW9uLA0KaXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gc3Vic3RpdHV0ZSB0aGUgZGlzdHJpYnV0aW9u IG9mIGhlYWRlciBjb21wcmVzc2lvbiBjb250ZXh0cy4NClRvIHF1b3RlIFJGQyA2Nzc1ICIuLi4g W3RoZXldIGdvIGhhbmQgaW4gaGFuZC4iDQoNCldpdGggdGhpcyBxdW90ZSBpbiBtaW5kLCBhZGRp bmcgdGhlIDZDTyB0byBSUEwgYW5kIHVzaW5nIHRoZW0gKFBJTyArIDZDTykgaW4gRElPcyBjb3Vs ZCBiZQ0KdGhlIGZpcnN0IHN0ZXAgaW4gZHJvcHBpbmcgdGhlIEFCUk8gb3ZlcmhlYWQgaW4gUkEg bWVzc2FnZXMgd2hlbiB1c2luZyBSUEwgaW4gYSA2TG9XUEFOLg0KQ3VycmVudGx5LCBydW5uaW5n IFJQTCBhbmQgNkxvV1BBTi1ORCBzaW11bHRhbmVvdXNseSB3b3VsZCByZXF1aXJlIHRvIGhhbmRs ZSB0aGUgdmVyc2lvbmluZw0Kb2YgRE9EQUdzIChieSBET0RBRyByb290KSBhbmQgdGhlIHZlcnNp b25pbmcgb2YgQUJSTyByZWxhdGVkIGluZm9ybWF0aW9uIChQSU8gKyA2Q08pIChieSA2TEJSKS4N CldpdGhvdXQgbG9va2luZyB0b28gbXVjaCBpbnRvIGRldGFpbHMsIGFuZCBwbGVhc2UgY29ycmVj dCBtZSBpZiBJIGFtIHdyb25nLCBidXQ6DQpUaGUgQUJSTyBhbmQgdGhlIERJTyBzZWVtIHRvIGhh dmUgYSBmZXcgc2ltaWxhcml0aWVzLiBCb3RoIGhhdmUgdmVyc2lvbmluZyBhbmQgYm90aCBoYXZl IGENCmNvbmNlcHQgb2YgYW4gIm9yaWdpbiIgKERPREFHLUlEIDwtPiA2TEJSIEFkZHJlc3MpLg0K DQpTbywgd291bGRuJ3QgaXQgYmUgcG9zc2libGUgdG8gYWJhbmRvbiB0aGUgQUJSTyBpbiBSUEwg ZG9tYWlucyB3aGVyZSBSUEwgYWxzbyBjb250cm9scyB0aGUgUElPcyBhbmQgNkNPcyA/DQoNCkNo ZWVycywNCkNlbmsNCk9uIDI0LjA5LjIwMTUgMTc6MjQsIFR1cm5lciwgUmFuZHkgd3JvdGU6DQoN ClllcywgSSB0aGluayB0aGF04oCZcyB3aGF0IEnigJltIGRvaW5nIHdpdGggdGhlIGNvbXByZXNz aW9uIGNvbnRleHQgb3B0aW9uIChzeW50YWN0aWNhbGx5IHJlY3JlYXRpbmcgaXQgZm9yIERJTykg 4oCTIHRoZSBvcHRpb25z4oCZIGludGVycHJldGF0aW9uIGlzIGlkZW50aWNhbCB0byBSRkMgNjc3 NSDigJMgdGhlIG9ubHkgZGlmZmVyZW5jZSBJIGNhbiBwb3NzaWJseSBzZWUgYmV0d2VlbiB0aGUg Njc3NSB0ZXh0IGFuZCB0aGUgb3B0aW9uIEkgcHJvcG9zZWQgaXMgcmVnYXJkaW5nIOKAnHdoZW7i gJ0gdGhlc2Ugb3B0aW9ucyBtaWdodCBhcHBlYXIgaW4gRElPcyBmcm9tIHRoZSByb290Lg0KDQpS YW5keQ0KDQoNClJlOiBbUm9sbF0gRElPIGNvbXByZXNzaW9uIG9wdGlvbg0KQ2Fyc3RlbiBCb3Jt YW5uIDxjYWJvQHR6aS5vcmc+PG1haWx0bzpjYWJvQHR6aS5vcmc+IFRodSwgMjQgU2VwdGVtYmVy IDIwMTUgMTQ6NDUgVVRDU2hvdyBoZWFkZXINCj4gWWVzLCBJIG1lbnRpb25lZCB0aGlzIGluIFBy YWd1ZSAodGhlIGZhY3QgdGhhdCA2Nzc1IDZDTyBhbHJlYWR5IGV4aXN0cykuDQo+ICBUaGUgWmln YmVlIE5BTiBncm91cCBkZWNpZGVkIHRoYXQgdGhlIGFkZGl0aW9uYWwgdHJhZmZpYyBpbXBvc2Vk IGJ5DQo+IG5laWdoYm9yIGRpc2NvdmVyeSB3YXMgbm90IHJlcXVpcmVkIChpbiB0aGUgcHJlc2Vu Y2Ugb2YgRElPIGFuZCBESU8NCj4gb3B0aW9ucykg4oCTIGhvd2V2ZXIsIHdlIHN0aWxsIHdvdWxk IGxpa2UgdG8gcmVjZWl2ZSBjb21wcmVzc2lvbiBvcHRpb25zLA0KPiBhbmQgd2XigJl2ZSBhbHJl YWR5IHBhaWQgdGhlIERJTyBwcmljZSB0cmFmZmljLXdpc2UsIHNvIHdl4oCZcmUgcGlnZ3kNCj4g YmFja2luZyB0aGUgY29tcHJlc3Npb24gb3B0aW9uIG9udG8gRElPcyB3ZeKAmXJlIGFscmVhZHkg aGFuZGxpbmcuDQo+DQo+DQo+DQo+IEnigJltIHRyeWluZyB0byBtYWludGFpbiB0aGUgY29udGV4 dCBsaWZlY3ljbGVzIHBlciA2Nzc1LCBzbyB0aGUgZXhpc3RpbmcNCj4gdGV4dCB3aWxsIGJlIG1v ZGlmaWVkIHRvIGluY2x1ZGUgdGhlIOKAnGxpZmV0aW1l4oCdIGZpZWxkIGluIHRoZSBvcHRpb24g KHRoZQ0KPiDigJxD4oCdIGJpdCBhbHJlYWR5IGV4aXN0cykNCg0KU28gaXMgdGhlIG9ic2VydmF0 aW9uIGZhaXIgdGhhdCB0aGlzIGlzIGVzc2VudGlhbGx5IGFib3V0IHJlcGFja2FnaW5nDQo2Q08g aW50byB0aGUgc3ludGFjdGljIGVudmlyb25tZW50IG9mIGEgUk9MTCBtZXNzYWdlPw0KDQpJIHRo aW5rIHdlIGNvdWxkIGRvIHRoYXQgZm9yIHRoZSByZXN0IG9mIHRoZSA2TG8tTkQgbWVzc2FnZXMg YXMgd2VsbCBhbmQNCnJlZHVjZSB0aGUgY29nbml0aXZlIGRpc3NvbmFuY2Ugb2Ygc2VuZGluZyBO RCBpbmZvcm1hdGlvbiB3aXRoIFJPTEwNCm1lc3NhZ2VzLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoN Cg0KUCBQTEVBU0UgQ09OU0lERVIgT1VSIEVOVklST05NRU5UIEJFRk9SRSBQUklOVElORyBUSElT IEVNQUlMLg0KDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgY29u ZmlkZW50aWFsIGFuZCBtYXkgYmUgbGVnYWxseSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQgb3IgYW4gYXV0aG9yaXplZCByZXByZXNlbnRhdGl2ZSBvZiBh biBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5 aW5nIG9yIGRpc3RyaWJ1dGluZyB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlLW1haWwgb3IgaXRz IGF0dGFjaG1lbnRzLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlLW1haWwgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLiBU aGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpSb2xsIG1haWxpbmcgbGlzdA0KDQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xs QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwN Cg0K --_000_982B626E107E334DBE601D979F31785C5C501EE5szxeml558mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OldlYmRpbmdzOw0KCXBhbm9zZS0xOjUgMyAxIDIgMSA1IDkgNiA3 IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFj azt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SWYgdGhlIHF1ZXN0aW9uIGlzIGFib3V0IG5ldHdvcmstd2lkZSBkaXNzZW1pbmF0 aW9uIG9mIGluZm9ybWF0aW9uLCB0aGVuIHRoZXJlIGFyZSBvdGhlciBjYW5kaWRhdGUgaW5mb3Jt YXRpb24gYXMgd2VsbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gb3IgZS5nLiB0aGVyZSBpcyBubyBnb29k IHdheSZuYnNwOyBvZiBkaXNzZW1pbmF0aW5nDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0wNSI+Y29yZS1yZDwv YT4gYWRkcmVzcyBpbmZvcm1hdGlvbiBpbiBtdWx0aWhvcCBMTE5zIChwbGVhc2UgY29ycmVjdCBt ZSBpZiB3cm9uZykuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGNvcmUtcmQgUkZDIG1lbnRpb25zIGRp c2NvdmVyeSBwcm9jZWR1cmVzIHdoaWNoIGFyZSBub3Qgd2VsbC1zdWl0ZWQgZm9yIExMTnMgKGZv ciBlLmcuDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLXJlc291cmNlLWRpcmVjdG9yeS0wNSNzZWN0aW9uLTUuMSI+DQpkcmFmdCBzZWN0aW9uIDUu MTwvYT4gc3VnZ2VzdHMgdXNlIG9mIG11bHRpY2FzdCBxdWVyeSB0byBmZXRjaCB0aGUgUkQgZGV0 YWlscykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBESU8gb3B0aW9u cyB0byBkaXNzZW1pbmF0ZSBzdWNoIGluZm9ybWF0aW9uIGluIGEgY29udHJvbGxlZCB3YXkgKHN1 Y2ggYXMgdGhlIHVzZSBvZiBESVMgdG8gcmVxdWVzdCBvcHRpb25zIGFzIFBhc2NhbCBzdWdnZXN0 ZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIG5vdGUgdGhh dCBjb3JlLXJkIGV4YW1wbGUgaGVyZSBzZXJ2ZXMganVzdCBhcyBhIHJlZmVyZW5jZSBmb3Igc29t ZXRoaW5nIHdoaWNoIHJlcXVpcmVzIG5ldHdvcmstd2lkZSBkaXNzZW1pbmF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGh1cyAmbmJzcDtpbWhvLCByYXRoZXIgdGhh biBoYXZpbmcgYSBkcmFmdCBzcGVjaWZpYyB0byBESU8gNkNPIGRpc3NlbWluYXRpb24gaXQgY2Fu IGJlIGdlbmVyYWxpemVkIHRvIHNvbWV0aGluZyBsaWtlIOKAnFJQTCBPcHRpb25zIGZvciBOZXR3 b3JrLXdpZGUgZGlzc2VtaW5hdGlvbiDigKYg4oCcIGFuZCBpbmNsdWRlIGFsbCAoZXZlbnR1YWxs eSBidWlsZCBvbiB0byBpdCkgJm5ic3A7dGhlDQogZGlmZmVyZW50IG9wdGlvbnMgcG9zc2libGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlJhaHVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5QYXNjYWwgVGh1YmVydCAocHRodWJlcnQpPGJyPg0KPGI+U2VudDo8L2I+ IDI1IFNlcHRlbWJlciAyMDE1IFBNIDA0OjIwPGJyPg0KPGI+VG86PC9iPiBSb3V0aW5nIE92ZXIg TG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jrczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1Jv bGxdIERJTyBjb21wcmVzc2lvbiBvcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGVsbG8gQ2Vuazxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIDZUaVNDSCBhcmNoaXRlY3R1 cmUgaXMgdGhlIGZpcnN0IElFVEYgZWZmb3J0IHRoYXQgY29tYmluZXMgUlBMIGFuZCA2TG9XUEFO IE5EIGFuZCBzdWdnZXN0cyBhIHdheSBvZiBwdXR0aW5nIHRoZW0gdG9nZXRoZXIuIFRoZSBlZmZv cnQgaXMgbm90IGNvbXBsZXRlIGJ1dCBpdCByYWlzZXMgdGhhdCBzb3J0IG9mIGNvZXhpc3RlbmNl IHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PbmUgb2YgdGhl IGNvbmNsdXNpb25zIGlzIHRoYXQgdGhlIDZCQlIgYW5kIHRoZSBSUEwgcm9vdCBzaG91bGQgYmUg Y29sbG9jYXRlZCBzbyB0aGF0IGEgcm9vdCBnZXRzIGEgZGV2aWNlIHVuaXF1ZSBJRCAoZnJvbSA2 TG9XUEFOIE5EKSBhbmQgYSBzZXF1ZW5jZSBjb3VudGVyIChmcm9tIFJQTCkgc2luY2UgaW4gcHJh Y3RpY2UgYm90aCBhcmUgbmVlZGVkIGZvciB0aGUNCiBiYWNrYm9uZSByb3V0ZXIgb3BlcmF0aW9u LiBUaGUgYXJjaGl0ZWN0dXJlIGFsc28gc3VnZ2VzdHMgdGhhdCBSUEwgREFPIHNlcXVlbmNlIGNv dW50ZXIgc2hvdWxkIGJlIHVzZWQgYXMgVElEIGluIGFuIGV4dGVuZGVkIEFSTyBvcHRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIGNvbmNsdXNpb24gbWF0Y2hl cyB5b3VycyB0aGF0IGV2ZW4gdGhvdWdoIHRoZSAyIHByb3RvY29scyBhcmUgZGVzaWduZWQgdG8g c3Vydml2ZSBzdGFuZCBhbG9uZSwgc29tZSBzaW1wbGlmaWNhdGlvbnMgYW5kIHBhaXJpbmdzIGFy ZSBuZWVkZWQgd2hlbiB0aGV5IGNvZXhpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5BQlJPIGlzIG5vdCB0aGUgb25seSBvbmUuIFRoZSBESU8gZG9lcyBub3QgcHJvdmlk ZSB0aGUgcm91dGVyIFNMTEEgZm9yIGluc3RhbmNlLCBzbyB0aGUgUkEgaXMgc3RpbGwgbmVlZGVk IGZvciB0aGF0IGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J 4oCZbGwgc3VwcG9ydCwgYW5kIGV2ZW4gY29udHJpYnV0ZSBpZiBuZWVkZWQsIHRvIHdvcmsgYXQg Uk9MTCB0aGF0IGFsbG93cyBBQlJPLCBTTExBTywgTVRVTyBhbmQgNkNPIGluIERJT3MuIFRoZSB3 b3JrIG1heSBpbXBhY3QgdGhlIERJUyB0aGF0IGNhbiBiZSB1c2VkIHRvIHJlcXVlc3Qgc29tZSBv cHRpb25zIHRoYXQgZG8gbm90IG5lZWQgdG8gYmUgY2FycmllZA0KIGluIGFsbCBESU9zIGluIGEg ZmFzaGlvbiBzaW1pbGFyIHRvIHRoZSBET0RBRyBDb25maWd1cmF0aW9uIG9wdGlvbi4gSXQgbWF5 IGFsc28gZGlzY3VzcyBpbiBtb3JlIGRldGFpbHMgaG93IERJT3MgYXJlIHNlbnQgb24gY29uc3Ry YWluZWQgbWF4aW11bSBmcmFtZSBzaXplIHdoZW4gbXVsdGlwbGUgb3B0aW9ucyBhcmUgbmVlZGVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UXVlc3Rpb24gdG8gdGhlIGNo YWlyczogaXMgdGhhdCB3b3JrIHdpdGhpbiBXSCBjaGFydGVyIGJvdW5kYXJpZXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFJvbGwgWzxhIGhyZWY9Im1haWx0bzpyb2xsLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5DZW5rIEfDvG5kb2dhbjxicj4NCjxiPlNlbnQ6PC9iPiBqZXVkaSAyNCBz ZXB0ZW1icmUgMjAxNSAyMjo1Njxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJvbGxA aWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUm9s bF0gRElPIGNvbXByZXNzaW9uIG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGVsbG8gQ2Fyc3Rl biwgUGFzY2FsLCBSYW5keSwgKjxicj4NCjxicj4NCkkgbGlrZSB0aGUgaWRlYSBvZiBoYXZpbmcg dGhlIDZDTyBpbmNsdWRlZCBpbnRvIFJQTCwgc2ltcGx5IGJlY2F1c2UgaXQgYWxyZWFkeSBpbmNs dWRlcyB0aGUgUElPPGJyPg0KYW5kIHRoZXJlIGlzIG5vIFJQTC1pc2ggd2F5IHRvIHRhZyBhbnkg cHJlZml4IGluZm9ybWF0aW9uIHdpdGggY29udGV4dCBpZGVudGlmaWVycyBpbiA2TG9XUEFOcy48 YnI+DQpIZW5jZSwgYW5kIHRoYXQgaXMganVzdCBteSBvcGluaW9uLCBpdCBpcyBub3QgZGVzaXJl ZCwgYnV0IGEgbmVjZXNzaXR5IHRvIGFkZCB0aGUgNkNPIHRvIFJQTCdzPGJyPg0Ka25vd24gb3B0 aW9ucyBsaXN0Ljxicj4NCjxicj4NCkFsc286IFJGQyA2Nzc1IzEuNCBjbGVhcmx5IHN0YXRlcyB0 aGF0IGluIG9yZGVyIHRvIHN1YnN0aXR1dGUgbXVsdGlob3AgcHJlZml4IGRpc3RyaWJ1dGlvbiw8 YnI+DQppdCBpcyBhbHNvIG5lY2Vzc2FyeSB0byBzdWJzdGl0dXRlIHRoZSBkaXN0cmlidXRpb24g b2YgaGVhZGVyIGNvbXByZXNzaW9uIGNvbnRleHRzLg0KPGJyPg0KVG8gcXVvdGUgUkZDIDY3NzUg JnF1b3Q7Li4uIFt0aGV5XSBnbyBoYW5kIGluIGhhbmQuJnF1b3Q7PGJyPg0KPGJyPg0KV2l0aCB0 aGlzIHF1b3RlIGluIG1pbmQsIGFkZGluZyB0aGUgNkNPIHRvIFJQTCBhbmQgdXNpbmcgdGhlbSAo UElPICYjNDM7IDZDTykgaW4gRElPcyBjb3VsZCBiZTxicj4NCnRoZSBmaXJzdCBzdGVwIGluIGRy b3BwaW5nIHRoZSBBQlJPIG92ZXJoZWFkIGluIFJBIG1lc3NhZ2VzIHdoZW4gdXNpbmcgUlBMIGlu IGEgNkxvV1BBTi48YnI+DQpDdXJyZW50bHksIHJ1bm5pbmcgUlBMIGFuZCA2TG9XUEFOLU5EIHNp bXVsdGFuZW91c2x5IHdvdWxkIHJlcXVpcmUgdG8gaGFuZGxlIHRoZSB2ZXJzaW9uaW5nPGJyPg0K b2YgRE9EQUdzIChieSBET0RBRyByb290KSBhbmQgdGhlIHZlcnNpb25pbmcgb2YgQUJSTyByZWxh dGVkIGluZm9ybWF0aW9uIChQSU8gJiM0MzsgNkNPKSAoYnkgNkxCUikuPGJyPg0KV2l0aG91dCBs b29raW5nIHRvbyBtdWNoIGludG8gZGV0YWlscywgYW5kIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkg YW0gd3JvbmcsIGJ1dDo8YnI+DQpUaGUgQUJSTyBhbmQgdGhlIERJTyBzZWVtIHRvIGhhdmUgYSBm ZXcgc2ltaWxhcml0aWVzLiBCb3RoIGhhdmUgdmVyc2lvbmluZyBhbmQgYm90aCBoYXZlIGE8YnI+ DQpjb25jZXB0IG9mIGFuICZxdW90O29yaWdpbiZxdW90OyAoRE9EQUctSUQgJmx0Oy0mZ3Q7IDZM QlIgQWRkcmVzcykuIDxicj4NCjxicj4NClNvLCB3b3VsZG4ndCBpdCBiZSBwb3NzaWJsZSB0byBh YmFuZG9uIHRoZSBBQlJPIGluIFJQTCBkb21haW5zIHdoZXJlIFJQTCBhbHNvIGNvbnRyb2xzIHRo ZSBQSU9zIGFuZCA2Q09zID88YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KQ2VuayA8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDI0LjA5LjIwMTUgMTc6MjQsIFR1cm5lciwgUmFuZHkgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIEkgdGhpbmsgdGhhdOKAmXMg d2hhdCBJ4oCZbSBkb2luZyB3aXRoIHRoZSBjb21wcmVzc2lvbiBjb250ZXh0IG9wdGlvbiAoc3lu dGFjdGljYWxseSByZWNyZWF0aW5nIGl0IGZvciBESU8pIOKAkyB0aGUgb3B0aW9uc+KAmSBpbnRl cnByZXRhdGlvbiBpcyBpZGVudGljYWwgdG8gUkZDIDY3NzUg4oCTIHRoZSBvbmx5IGRpZmZlcmVu Y2UgSSBjYW4gcG9zc2libHkgc2VlIGJldHdlZW4gdGhlIDY3NzUgdGV4dCBhbmQgdGhlIG9wdGlv bg0KIEkgcHJvcG9zZWQgaXMgcmVnYXJkaW5nIOKAnHdoZW7igJ0gdGhlc2Ugb3B0aW9ucyBtaWdo dCBhcHBlYXIgaW4gRElPcyBmcm9tIHRoZSByb290Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJhbmR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmU6IFtSb2xsXSBESU8gY29tcHJlc3Npb24gb3B0aW9uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYXJzdGVuIEJvcm1hbm4gPGEgaHJlZj0i bWFpbHRvOmNhYm9AdHppLm9yZyI+Jmx0O2NhYm9AdHppLm9yZyZndDs8L2E+IFRodSwgMjQgU2Vw dGVtYmVyIDIwMTUgMTQ6NDUgVVRDU2hvdyBoZWFkZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgWWVzLCBJIG1lbnRpb25lZCB0aGlzIGluIFByYWd1ZSAodGhlIGZh Y3QgdGhhdCA2Nzc1IDZDTyBhbHJlYWR5IGV4aXN0cykuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7IFRoZSBaaWdiZWUgTkFOIGdyb3VwIGRlY2lkZWQgdGhh dCB0aGUgYWRkaXRpb25hbCB0cmFmZmljIGltcG9zZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgbmVpZ2hib3IgZGlzY292ZXJ5IHdhcyBub3QgcmVxdWlyZWQg KGluIHRoZSBwcmVzZW5jZSBvZiBESU8gYW5kIERJTzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyBvcHRpb25zKSDigJMgaG93ZXZlciwgd2Ugc3RpbGwgd291bGQgbGlr ZSB0byByZWNlaXZlIGNvbXByZXNzaW9uIG9wdGlvbnMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IGFuZCB3ZeKAmXZlIGFscmVhZHkgcGFpZCB0aGUgRElPIHByaWNl IHRyYWZmaWMtd2lzZSwgc28gd2XigJlyZSBwaWdneTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyBiYWNraW5nIHRoZSBjb21wcmVzc2lvbiBvcHRpb24gb250byBESU9z IHdl4oCZcmUgYWxyZWFkeSBoYW5kbGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5i c3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSeKAmW0gdHJ5aW5nIHRvIG1haW50YWlu IHRoZSBjb250ZXh0IGxpZmVjeWNsZXMgcGVyIDY3NzUsIHNvIHRoZSBleGlzdGluZzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyB0ZXh0IHdpbGwgYmUgbW9kaWZpZWQg dG8gaW5jbHVkZSB0aGUg4oCcbGlmZXRpbWXigJ0gZmllbGQgaW4gdGhlIG9wdGlvbiAodGhlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IOKAnEPigJ0gYml0IGFscmVh ZHkgZXhpc3RzKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpcyB0aGUgb2JzZXJ2YXRpb24g ZmFpciB0aGF0IHRoaXMgaXMgZXNzZW50aWFsbHkgYWJvdXQgcmVwYWNrYWdpbmc8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjZDTyBpbnRvIHRoZSBzeW50YWN0aWMgZW52aXJv bm1lbnQgb2YgYSBST0xMIG1lc3NhZ2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg d2UgY291bGQgZG8gdGhhdCBmb3IgdGhlIHJlc3Qgb2YgdGhlIDZMby1ORCBtZXNzYWdlcyBhcyB3 ZWxsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVkdWNlIHRoZSBj b2duaXRpdmUgZGlzc29uYW5jZSBvZiBzZW5kaW5nIE5EIGluZm9ybWF0aW9uIHdpdGggUk9MTDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWVzc2FnZXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdyw7zDn2UsIENhcnN0ZW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2ViZGluZ3M7Y29sb3I6 Z3JlZW4iPlA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmVl biI+IFBMRUFTRSBDT05TSURFUiBPVVIgRU5WSVJPTk1FTlQgQkVGT1JFIFBSSU5USU5HIFRISVMg RU1BSUwuDQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgYmUgbGVnYWxseSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQgb3IgYW4gYXV0aG9yaXplZCByZXByZXNlbnRhdGl2ZSBv ZiBhbiBpbnRlbmRlZA0KIHJlY2lwaWVudCwgeW91IGFyZSBwcm9oaWJpdGVkIGZyb20gdXNpbmcs IGNvcHlpbmcgb3IgZGlzdHJpYnV0aW5nIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGUtbWFpbCBv ciBpdHMgYXR0YWNobWVudHMuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgcmV0dXJuIGUtbWFp bCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlIGFuZA0KIGFueSBhdHRhY2ht ZW50cy4gVGhhbmsgeW91LiA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpncmVlbiI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5Sb2xsIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_982B626E107E334DBE601D979F31785C5C501EE5szxeml558mbschi_-- From nobody Tue Oct 27 02:47:12 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0631A6F47 for ; Tue, 27 Oct 2015 02:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbmvAoRYBAsL for ; Tue, 27 Oct 2015 02:47:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635CA1A6F41 for ; Tue, 27 Oct 2015 02:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24331; q=dns/txt; s=iport; t=1445939227; x=1447148827; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZOuk6yh+TRNjG7Q8Ap1+x0Cmj6kw5O70SvXUV0kLUVc=; b=DqnNiyjjYyytq+NUv+r4sMIlkskvhARSCQHBdnkalVmCCMSzzwr8jNl+ tSAcIIf+e2j3g5nvAkKeddaGQ3uTM1yYjj0Cz1q+T75kfm078jBfeTbDX zTgrDmdecVqapZ/M3TtI76u0VZe9ihtzHL3Xx3IQ+5TfHqWQv71Ks9/jo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgD4Ri9W/5pdJa1egmlNVG++agENgVoXAQuFdwKBOzgUAQEBAQEBAYEKhDIBAQEDAQEBAQkbBjoHEAsCAQgRAQMBASEHBycLFAMGCAEBBBOIKAgNxXEBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZ3ghCBaIEGhB8LEQECSgEKAQaDFIEUBZI6KINVAYUbgnCFF4FZhD+WFgEfAQFCghEdgVZyAYQtgUABAQE X-IronPort-AV: E=Sophos;i="5.20,204,1444694400"; d="scan'208,217";a="201659710" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2015 09:47:06 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t9R9l6bx013091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Oct 2015 09:47:06 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 04:46:41 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 04:46:42 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] DIO compression option Thread-Index: AdD23JVMqzl6YbyQR+67lzbuc7ttTv//14aAgAC/BAD/zTnE0IBlr0xu Date: Tue, 27 Oct 2015 09:46:42 +0000 Message-ID: <78426250-150C-45C4-9A4D-9699EBBB2648@cisco.com> References: <56046359.4070202@gmail.com> <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com>, <982B626E107E334DBE601D979F31785C5C501EE5@szxeml558-mbs.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5C501EE5@szxeml558-mbs.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_78426250150C45C49A4D9699EBBB2648ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:47:10 -0000 --_000_78426250150C45C49A4D9699EBBB2648ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please do not overload the control plane with non control info! RPL has a multicast built in and we could leverage that easily for all node= s with scope based on Ralph's work for scoping. The flood could be using the dodag redundant shape for Better coverage. Cheers, Pascal Le 27 oct. 2015 =E0 17:14, Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 L= abs) > a =E9crit : If the question is about network-wide dissemination of information, then th= ere are other candidate information as well. For e.g. there is no good way of disseminating core-rd address information in mult= ihop LLNs (please correct me if wrong). The core-rd RFC mentions discovery procedures which are not well-suited for= LLNs (for e.g. draft section 5.1 suggests use of multicast query to fe= tch the RD details). It would be nice to have DIO options to disseminate such information in a c= ontrolled way (such as the use of DIS to request options as Pascal suggeste= d). Please note that core-rd example here serves just as a reference for someth= ing which requires network-wide dissemination. Thus imho, rather than having a draft specific to DIO 6CO dissemination it= can be generalized to something like =93RPL Options for Network-wide disse= mination =85 =93 and include all (eventually build on to it) the different= options possible. Cheers, Rahul From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: 25 September 2015 PM 04:20 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] DIO compression option Hello Cenk The 6TiSCH architecture is the first IETF effort that combines RPL and 6LoW= PAN ND and suggests a way of putting them together. The effort is not compl= ete but it raises that sort of coexistence problem. One of the conclusions is that the 6BBR and the RPL root should be collocat= ed so that a root gets a device unique ID (from 6LoWPAN ND) and a sequence = counter (from RPL) since in practice both are needed for the backbone route= r operation. The architecture also suggests that RPL DAO sequence counter s= hould be used as TID in an extended ARO option. This conclusion matches yours that even though the 2 protocols are designed= to survive stand alone, some simplifications and pairings are needed when = they coexist. ABRO is not the only one. The DIO does not provide the router SLLA for inst= ance, so the RA is still needed for that as well. I=92ll support, and even contribute if needed, to work at ROLL that allows = ABRO, SLLAO, MTUO and 6CO in DIOs. The work may impact the DIS that can be = used to request some options that do not need to be carried in all DIOs in = a fashion similar to the DODAG Configuration option. It may also discuss in= more details how DIOs are sent on constrained maximum frame size when mult= iple options are needed. Question to the chairs: is that work within WH charter boundaries? Cheers, Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk G=FCndogan Sent: jeudi 24 septembre 2015 22:56 To: roll@ietf.org Subject: Re: [Roll] DIO compression option Hello Carsten, Pascal, Randy, * I like the idea of having the 6CO included into RPL, simply because it alre= ady includes the PIO and there is no RPL-ish way to tag any prefix information with context iden= tifiers in 6LoWPANs. Hence, and that is just my opinion, it is not desired, but a necessity to a= dd the 6CO to RPL's known options list. Also: RFC 6775#1.4 clearly states that in order to substitute multihop pref= ix distribution, it is also necessary to substitute the distribution of header compression c= ontexts. To quote RFC 6775 "... [they] go hand in hand." With this quote in mind, adding the 6CO to RPL and using them (PIO + 6CO) i= n DIOs could be the first step in dropping the ABRO overhead in RA messages when using RPL = in a 6LoWPAN. Currently, running RPL and 6LoWPAN-ND simultaneously would require to handl= e the versioning of DODAGs (by DODAG root) and the versioning of ABRO related information (P= IO + 6CO) (by 6LBR). Without looking too much into details, and please correct me if I am wrong,= but: The ABRO and the DIO seem to have a few similarities. Both have versioning = and both have a concept of an "origin" (DODAG-ID <-> 6LBR Address). So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL al= so controls the PIOs and 6COs ? Cheers, Cenk On 24.09.2015 17:24, Turner, Randy wrote: Yes, I think that=92s what I=92m doing with the compression context option = (syntactically recreating it for DIO) =96 the options=92 interpretation is = identical to RFC 6775 =96 the only difference I can possibly see between th= e 6775 text and the option I proposed is regarding =93when=94 these options= might appear in DIOs from the root. Randy Re: [Roll] DIO compression option Carsten Bormann Thu, 24 September 2015 = 14:45 UTCShow header > Yes, I mentioned this in Prague (the fact that 6775 6CO already exists). > The Zigbee NAN group decided that the additional traffic imposed by > neighbor discovery was not required (in the presence of DIO and DIO > options) =96 however, we still would like to receive compression options, > and we=92ve already paid the DIO price traffic-wise, so we=92re piggy > backing the compression option onto DIOs we=92re already handling. > > > > I=92m trying to maintain the context lifecycles per 6775, so the existing > text will be modified to include the =93lifetime=94 field in the option (= the > =93C=94 bit already exists) So is the observation fair that this is essentially about repackaging 6CO into the syntactic environment of a ROLL message? I think we could do that for the rest of the 6Lo-ND messages as well and reduce the cognitive dissonance of sending ND information with ROLL messages. Gr=FC=DFe, Carsten P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_78426250150C45C49A4D9699EBBB2648ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Please do not overload the control plane with non control info!

RPL has a multicast built in and we could le= verage that easily for all nodes with scope based on Ralph's work for scopi= ng.

The flood could be using the dodag redundant= shape for Better coverage.

Cheers,


Pascal

Le 27 oct. 2015 =E0 17:14, Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 L= abs) <rahul.jadhav@huawei.com= > a =E9crit :

If the question is abo= ut network-wide dissemination of information, then there are other candidat= e information as well.

For e.g. there is no g= ood way  of disseminating core-rd address information in multihop LLNs (please correct me if w= rong).

The core-rd RFC mentio= ns discovery procedures which are not well-suited for LLNs (for e.g. draft section 5.1 suggests use of multicast query to fetch the RD detai= ls).

It would be nice to ha= ve DIO options to disseminate such information in a controlled way (such as= the use of DIS to request options as Pascal suggested).<= /p>

 

Please note that core-= rd example here serves just as a reference for something which requires net= work-wide dissemination.

 

Thus  imho, rathe= r than having a draft specific to DIO 6CO dissemination it can be generaliz= ed to something like =93RPL Options for Network-wide dissemination =85 =93 = and include all (eventually build on to it)  the different options possible.

 

Cheers,

Rahul

 

 

From: Roll [ma= ilto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 25 September 2015 PM 04:20
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] DIO compression option

 

Hello Cenk<= /span>

 

The 6TiSCH architectur= e is the first IETF effort that combines RPL and 6LoWPAN ND and suggests a = way of putting them together. The effort is not complete but it raises that= sort of coexistence problem.

 

One of the conclusions= is that the 6BBR and the RPL root should be collocated so that a root gets= a device unique ID (from 6LoWPAN ND) and a sequence counter (from RPL) sin= ce in practice both are needed for the backbone router operation. The architecture also suggests that RPL DAO seq= uence counter should be used as TID in an extended ARO option.

 

This conclusion matche= s yours that even though the 2 protocols are designed to survive stand alon= e, some simplifications and pairings are needed when they coexist.

 

ABRO is not the only o= ne. The DIO does not provide the router SLLA for instance, so the RA is sti= ll needed for that as well.

 

I=92ll support, and ev= en contribute if needed, to work at ROLL that allows ABRO, SLLAO, MTUO and = 6CO in DIOs. The work may impact the DIS that can be used to request some o= ptions that do not need to be carried in all DIOs in a fashion similar to the DODAG Configuration option. It may= also discuss in more details how DIOs are sent on constrained maximum fram= e size when multiple options are needed.

 

Question to the chairs= : is that work within WH charter boundaries?

 

Cheers,

 

Pascal

 

From:= Roll [mailto:roll-bounces@ietf.org] On Behalf Of Cenk G=FCndogan
Sent: jeudi 24 septembre 2015 22:56
To: roll@ietf.org
Subject: Re: [Roll] DIO compression option

 

Hello Carsten, Pascal= , Randy, *

I like the idea of having the 6CO included into RPL, simply because it alre= ady includes the PIO
and there is no RPL-ish way to tag any prefix information with context iden= tifiers in 6LoWPANs.
Hence, and that is just my opinion, it is not desired, but a necessity to a= dd the 6CO to RPL's
known options list.

Also: RFC 6775#1.4 clearly states that in order to substitute multihop pref= ix distribution,
it is also necessary to substitute the distribution of header compression c= ontexts.
To quote RFC 6775 "... [they] go hand in hand."

With this quote in mind, adding the 6CO to RPL and using them (PIO + 6C= O) in DIOs could be
the first step in dropping the ABRO overhead in RA messages when using RPL = in a 6LoWPAN.
Currently, running RPL and 6LoWPAN-ND simultaneously would require to handl= e the versioning
of DODAGs (by DODAG root) and the versioning of ABRO related information (P= IO + 6CO) (by 6LBR).
Without looking too much into details, and please correct me if I am wrong,= but:
The ABRO and the DIO seem to have a few similarities. Both have versioning = and both have a
concept of an "origin" (DODAG-ID <-> 6LBR Address).

So, wouldn't it be possible to abandon the ABRO in RPL domains where RPL al= so controls the PIOs and 6COs ?

Cheers,
Cenk

On 24.09.2015 17:24, Turner, Randy wrote:=

 

Yes, I think that=92s what I=92m doing with the comp= ression context option (syntactically recreating it for DIO) =96 the option= s=92 interpretation is identical to RFC 6775 =96 the only difference I can = possibly see between the 6775 text and the option I proposed is regarding =93when=94 these options might appear in DIOs from= the root.

 

Randy

 

 

Re: [Roll] DIO compression option

Carsten Bormann <= cabo@tzi.org> Thu, 24 September 2015 14:45 UTCShow header=

> Yes, I mentioned this in Prague (the fact that = 6775 6CO already exists).

>  The Zigbee NAN group decided that the add= itional traffic imposed by

> neighbor discovery was not required (in the pre= sence of DIO and DIO

> options) =96 however, we still would like to re= ceive compression options,

> and we=92ve already paid the DIO price traffic-= wise, so we=92re piggy

> backing the compression option onto DIOs we=92r= e already handling.

>

> 

>

> I=92m trying to maintain the context lifecycles= per 6775, so the existing

> text will be modified to include the =93lifetim= e=94 field in the option (the

> =93C=94 bit already exists)

 

So is the observation fair that this is essentially = about repackaging

6CO into the syntactic environment of a ROLL message= ?

 

I think we could do that for the rest of the 6Lo-ND = messages as well and

reduce the cognitive dissonance of sending ND inform= ation with ROLL

messages.

 

Gr=FC=DFe, Carsten

 

P PLEASE CO= NSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) = is confidential and may be legally privileged. If you are not an intended r= ecipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the info= rmation in this e-mail or its attachments. If you have received this e-mail= in error, please notify the sender immediately by return e-mail and delete= all copies of this message and any attachments. Thank you. 



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.iet=
f.org/mailman/listinfo/roll

 

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ie= tf.org/mailman/listinfo/roll
--_000_78426250150C45C49A4D9699EBBB2648ciscocom_-- From nobody Fri Oct 30 11:43:46 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8724E1B30B8 for ; Fri, 30 Oct 2015 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.772 X-Spam-Level: X-Spam-Status: No, score=0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wNOV5poFb1W for ; Fri, 30 Oct 2015 11:43:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B8C1B30B9 for ; Fri, 30 Oct 2015 11:43:39 -0700 (PDT) Received: from sandelman.ca (unknown [204.239.250.1]) by relay.sandelman.ca (Postfix) with ESMTPS id E1C5022094 for ; Fri, 30 Oct 2015 14:42:39 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 91B67CA0EA for ; Fri, 30 Oct 2015 09:44:02 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <7edf9ea4a75d4051a6779e4c16304cce@XCH-RCD-001.cisco.com> References: <7edf9ea4a75d4051a6779e4c16304cce@XCH-RCD-001.cisco.com> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Mon, 19 Oct 2015 10:29:05 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Oct 2015 09:44:02 -0400 Message-ID: <24084.1446212642@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] DAO projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 18:43:40 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > We did not have much discussion on this topic since the IETF. So in > preparation of Yokohama, I'd like to sense interest in that > topic. Continue, or drop? Continue. I see the work as critical to the future: it lets us build much bigger networks with far less congestion at the root, without the risk of running out of routing table entries. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJWM3QgAAoJEKD0KQ7Gj3P2TLsIALI4ujPrFRp5hg9pFFsGBEUH iMK4KvbRqpchg5D/Wzw+2NdMqyfo7Ez/XIG3Xf5t42/XBilCgXO8GcdNaA60lGoB B8/oHQ5D0pCoKXW4c+MyddBk4XYUm5IfUJJlrkMDh2gtZQ+pGxOi2z9lscYcnuV9 nzSS4x6+axpeTya2spBCWZcIr2cayP91wCsKF/CMQajVjWUb3/Cve7pJGer2ABFz /7jIXNb1RhEQS7Axxaw7j5EO51+mwoYzuqf6H7fr4VqoHOASMvnRbLTE2taprbWH mGK59QFTJK6iKbxQ0Mkkurb5S+yYGuILYgNx05qtmpx7mjStZ0NWba2xf5VveL8= =gsEJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 04:56:12 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454301A89B1 for ; Sat, 31 Oct 2015 04:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVi40QbCKww8 for ; Sat, 31 Oct 2015 04:56:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235741A89A9 for ; Sat, 31 Oct 2015 04:56:10 -0700 (PDT) Received: from sandelman.ca (y255183.ppp.asahi-net.or.jp [118.243.255.183]) by relay.sandelman.ca (Postfix) with ESMTPS id 6C66C2208B for ; Sat, 31 Oct 2015 07:56:08 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A13A2CA0EE for ; Fri, 30 Oct 2015 23:18:31 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> References: <56046359.4070202@gmail.com> <49ca8038c29a4498b23281c1ee7ee48a@XCH-RCD-001.cisco.com> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Fri, 25 Sep 2015 08:19:34 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Oct 2015 23:18:31 -0400 Message-ID: <25054.1446261511@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] DIO compression option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 11:56:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {clearly, I should have read all of this thread earlier} Pascal Thubert (pthubert) wrote: > I=E2=80=99ll support, and even contribute if needed, to work at ROLL = that > allows ABRO, SLLAO, MTUO and 6CO in DIOs. The work may impact the DIS > that can be used to request some options that do not need to be carri= ed > in all DIOs in a fashion similar to the DODAG Configuration option. It > may also discuss in more details how DIOs are sent on constrained > maximum frame size when multiple options are needed. > Question to the chairs: is that work within WH charter boundaries? No, it doesn't fit into the words of our current charter. Spirit: I think so.... our goal is to make compression better... if we can distribute 6CO better, that would help, I think. I've asked Ines to add this to our agenda. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJWNDMFAAoJEKD0KQ7Gj3P2yA0H/ApgSEuUi2v3mbyL04kBZ/DI AAkdC/I2GXpBHAMgXuPDnSiED7t/WGOC6IbKeKr/OtHM8S4c5oMzzgKUIWecvEH4 dl6HSc9Zsl2feyvufxirCs/5Y8PFAWMsa7M2rjpGIyYtujdRAsPYuJWcN1w4SvLv KC8gfZPv1HUnXz8p5/X/+FMVEUI33UXD1sWHmkEI8zRo7XbYNVaWbyaZklQYPzzH MpAPB7QsdbPMtGXE+jeAu5NF/rc9xcWOTUli1UnjMfXSmTOvz57cTQg0nsAonnYX OSUoJHc+aRxprsja/bmh8wKguVMxCva11sx7LmNCp89QGNf0aCNc8J3wuGyQfbU= =dqqK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 04:56:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAD71A89B3 for ; Sat, 31 Oct 2015 04:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_7Xh-_LAErn for ; Sat, 31 Oct 2015 04:56:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C421A8971 for ; Sat, 31 Oct 2015 04:56:10 -0700 (PDT) Received: from sandelman.ca (y255183.ppp.asahi-net.or.jp [118.243.255.183]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F16C2208C for ; Sat, 31 Oct 2015 07:56:08 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 722F9CA0F5 for ; Sat, 31 Oct 2015 01:51:37 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <5624D0B2.2030803@gmail.com> References: <5617AB01.7060703@gmail.com> <5624D0B2.2030803@gmail.com> Comments: In-reply-to =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FCenk=5FG=3Dc3=3Dbcndo?= =?us-ascii?Q?gan=3F=3D?= message dated "Mon, 19 Oct 2015 13:14:58 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 31 Oct 2015 01:51:37 -0400 Message-ID: <28117.1446270697@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] RPL-aware or not RPL-aware, that's the question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 11:56:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cenk G=C3=BCndogan wrote: > What I was actually aiming for was the `E` flag in the Transit Option > within DAOs, that marks routes as external routes when they weren't > set-up by RPL. This information is propagated upwards the DAG and hen= ce By external routes, you mean routes which are not part of the DODAG. (For instance, in a homenet, the routes to the other parts of the homnet) I think that in many LLNs, a single ::/0 route would be injected as E, and let the DODAG route sort it out.=20=20 In that case, unless you know the node is within the DODAG, and you are in storing mode, you pretty much always have to use use an IPIP addressed to t= he DODAG root. Or to put it another way, I think the only time you don't need to use an IPIP is: 1) traffic to another RPL node and there are no 6lo/ND nodes. 2) storing mode is used (so no RH3 needed at root) 3) the sender inserts the RPI. How can you know (1)? Well, either by construction. I think that we should have an attribute in the DIO that says whether there are any non-RPL nodes. The DODAG root can know this from a new attribute we'd have to put into the DAOs. It's a boolean: as soon as there is at lea= st one ND-node, then all nodes wind up using IPIP. [and this is why the compression is so important] =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJWNFbnAAoJEKD0KQ7Gj3P28QQH/RyQ/ds+e4ohxjyU2lntWLF1 sPNI2BQ1wkm8vGeckcdjg7fGrAqlyCqfswZDMOunergV2OPOBXKNLbg9/Ma4LB0g X1PynO3rdPdPWgIg/EUxwnNYht4lAyMColQaHvOT2plCb0ckC8idXD6YRHNGT2EW FLinYtVpRLAAWobFi6zrZJ6u7kae8dc6JPCXOcrLUqZDc4jUoh95s5zvROwnLQdy LU01D76Du54rY3iiT9MybIOZEesX/tFfsCQz+N0pgc/bGf2udkgVbNBcoVRQ15JU KJK/LDj/Eb/MfzNJmxbZG/tTEbdHULATie8grZlj9mZl/shNfBApo1yJJtWgT9Y= =T2bK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 04:56:20 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06A1A89E0 for ; Sat, 31 Oct 2015 04:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIraot2X7tPF for ; Sat, 31 Oct 2015 04:56:12 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B530B1A89B1 for ; Sat, 31 Oct 2015 04:56:12 -0700 (PDT) Received: from sandelman.ca (y255183.ppp.asahi-net.or.jp [118.243.255.183]) by relay.sandelman.ca (Postfix) with ESMTPS id 56BB72208B for ; Sat, 31 Oct 2015 07:56:11 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 44DD5CA0F2 for ; Sat, 31 Oct 2015 00:55:00 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: References: <6d21d0f86ab14ae7a99ff9fe6873b1fd@XCH-RCD-001.cisco.com> <560AFDBB.8050505@gmail.com> <560B68B2.6030501@fbk.eu> <245E0C92-6ED6-426B-95E1-09BA8736F1BC@sics.se> <560D8386.6000502@fbk.eu> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Fri, 02 Oct 2015 13:04:54 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 31 Oct 2015 00:55:00 -0400 Message-ID: <26492.1446267300@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Roll] Semantics of DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 11:56:13 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > What I read here boils down to a limited diffusion algorithm. We tried > to avoid that in RPL because any movement within the convergence would > cause a deadlock. IOW if every node waits for (all of) the parents to Are you saying that waiting for an ACK from the root will result in an unstable/non-convergent algorithm? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJWNEmiAAoJEKD0KQ7Gj3P2g6QIAI5fmM7H0Xe7ABDnlueYdMkI mQ+qZMao4RZfojJK7F5nNQ/uf/FFsjCIi8PlJaKfUairkDCNrFhfszaXQBkyNuyZ b5HiDPtXbnhEq5q52JoChagOicrRM6Ovpbry0V5qXgilJwYoTAHdbSNr4qshU5Z8 YRNW84+xcFJcejGb/gtdWl+Xn1bwwcxVbLDjT6T3eWmjVing/W1454vf7w+1FKa4 pe/x6K2TEUyKPsjaN56+p9+4c7EVgA3LAzekNScCmcTTEZ/t0+7bi0Zu+qzISTqA AEXxeyeJb5pRQP9EvRwi7ZjoaV2w8OE7wQcDFMi27HUaAg70LZ8oA8H0KlHv+2U= =j6ba -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 05:01:33 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3B1A8A92 for ; Sat, 31 Oct 2015 05:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MSgvyWyvEgQ for ; Sat, 31 Oct 2015 05:01:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3671A89E1 for ; Sat, 31 Oct 2015 05:01:29 -0700 (PDT) Received: from sandelman.ca (y255183.ppp.asahi-net.or.jp [118.243.255.183]) by relay.sandelman.ca (Postfix) with ESMTPS id 5A9292208C; Sat, 31 Oct 2015 07:56:11 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 21FADCA0EB; Fri, 30 Oct 2015 22:52:31 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <560318EE.5050509@tzi.org> References: <560318EE.5050509@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Wed, 23 Sep 2015 23:26:06 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Oct 2015 22:52:30 -0400 Message-ID: <24551.1446259950@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: [Roll] replacing RFC6775 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 12:01:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > (I also would like to see a resolution of the question whether ROLL is > now planning to officially replace RFC 6775 for all intents and > purposes. We could have done that but didn't. Was there a point? B= ut > that is maybe a separate question.) Are you asking if we intend to replace ND with efficient-ND, or are you asking if ROLL networks will do no ND at all? In our analysis of the RPI/RH3, one of the things that came up is that when there are leafs which are plain 6lowpan nodes, which run 6775 (or classic ND), that we have a problem. The issue is that the sending system needs to know whether or not the end node is a ROLL or 6775 node prior to sending. While the DODAG root can know this, other nodes can not a-priori. The reas= on is because an IPIP header needs to be inserted (or not), and the IPIP header needs to be accurately addressed.=20=20 This is in the useofrpi ID, and we are trying to explain it in some diagram= s. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJWNCzsAAoJEKD0KQ7Gj3P2VDIIAIDulJsG+nu5Ez9Vkw+PT9y5 svLwTdGb0kKtQlcGxdrNZnSAM8a/hkTMA/mqIDDPXZb0iysyXcJpDFSFmBpOjI74 X3cSqRO2qmvyAg74OenegRHEzxi3z2D0p9oxMJzY+U1PafvXyj9NpWUl75DaSZZM wxy7YMLAUtjNeS3/41y02nZLIqIIzjHydNAVmfwaYWHyiOPGEuP83YJMsXjk/+AL 4F+3ZWDOadOX58NQw0mp2ZG72vqB1Dqc6MMCDv7x5R+RsezssrEcAsJd9oKQzGgt 3axTHczC82ILg1HkFtFfT1XaMKRdLFfU36myhl9BMngCxFfqNbnu3SRgj9hnPgE= =EEgQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 05:39:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96531ACEB1 for ; Sat, 31 Oct 2015 05:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvJMUoO12YFD for ; Sat, 31 Oct 2015 05:39:24 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC21D1ACE86 for ; Sat, 31 Oct 2015 05:39:23 -0700 (PDT) Received: from DB5PR01MB1079.eurprd01.prod.exchangelabs.com (10.162.152.141) by DB5PR01MB1448.eurprd01.prod.exchangelabs.com (10.164.36.26) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sat, 31 Oct 2015 12:39:06 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com (10.162.152.142) by DB5PR01MB1079.eurprd01.prod.exchangelabs.com (10.162.152.141) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sat, 31 Oct 2015 12:39:06 +0000 Received: from DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) by DB5PR01MB1080.eurprd01.prod.exchangelabs.com ([10.162.152.142]) with mapi id 15.01.0312.014; Sat, 31 Oct 2015 12:39:06 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] replacing RFC6775 Thread-Index: AQHRE9PlKFG+wIu6FkqrDlaObXVW9p6Fipvq Date: Sat, 31 Oct 2015 12:39:06 +0000 Message-ID: References: <560318EE.5050509@tzi.org>,<24551.1446259950@sandelman.ca> In-Reply-To: <24551.1446259950@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [70.193.135.159] x-microsoft-exchange-diagnostics: 1; DB5PR01MB1079; 5:YW/ktxW5dGVKZJxhG/7QUSKiSxHwk72/upMEEaet+2Vw7aUR+4QGW+c2M1zHNNRUwTzbOMBQqXvOMud0GBWh8nUop0TunlET8HkHnUlB5dLtFA9JedEmCCsTq0cH1TYiiIMeQ8RkU13CULmBLv9cKA==; 24:8gOh91MCXMUQS+kC6G8Baf/w8q756EO31yH1ZOuTl9MQ6Ok3qtQkMy64P4NKMz9zK2k+pVCrgFeP1p2zTf5tbf6ym5SVNDHhWUcbmAz9vNA=; 20:NRSJPmQwYwF/lqkiW9E9E5rD5wzsRIbwLqtxrAIUYpS1A75mPUuBe9VwPgdo0rfU9yqLMl53QmMjHnPQ5SC8MA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1079; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:DB5PR01MB1079; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1079; x-forefront-prvs: 07467C4D33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(24454002)(106356001)(101416001)(5004730100002)(122556002)(2900100001)(5002640100001)(2950100001)(36756003)(5007970100001)(106116001)(15975445007)(450100001)(86362001)(105586002)(40100003)(107886002)(19580405001)(189998001)(19580395003)(83716003)(5001960100002)(102836002)(82746002)(110136002)(5890100001)(92566002)(11100500001)(5008740100001)(33656002)(66066001)(87936001)(81156007)(77096005)(97736004)(10400500002)(50986999)(54356999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1079; H:DB5PR01MB1080.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2015 12:39:06.1012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1079 X-Microsoft-Exchange-Diagnostics: 1; DB5PR01MB1448; 2:K0JjTM/Ew8KCH2f0XhhqFCo1A7Mz/ptshQunEfaxRLlSfKWpqFnb/gAZ6AUp+8Ehyurb2fDiTnhXZwcD0G8tHxGEJfDt9mBFc5Dt7aST7nZokC+xvNQ1VUG8Qe+TaKksPHJ57MvPGTp3eHb1OAeWbHD5YagMGTy4j3mxeEbYqzw=; 23:W/RmClKaCGBqMFnnZF+HUAzY399nWrlG7gIbnOjbmxe2HU1wjYupNK2R4c8kytKoLtR+0aMxHnYBxf7/r1vYd0fcMXpfSP37c1xqjQwU8XnCRxaw28kFYkTpi/xjkk2SGZsy+lctNwF8ynFeKMtAugMSwmWgjFM7AlCx9mNuRVdeGxHlVngKudmT18eYFcvg X-OriginatorOrg: landisgyr.com Archived-At: Subject: Re: [Roll] replacing RFC6775 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 12:39:27 -0000 My pitch in Prague was that there were ROLL networks that do not need ND bu= t could use some valuable options carried by ND - the DIO compression conte= xt draft reflects one of the higher value options that I could think of. Th= ere may still be LoWPAN scenarios that could still benefit from 6775 Randy > On Oct 31, 2015, at 8:01 AM, Michael Richardson w= rote: > > > Carsten Bormann wrote: >> (I also would like to see a resolution of the question whether ROLL is >> now planning to officially replace RFC 6775 for all intents and >> purposes. We could have done that but didn't. Was there a point? But >> that is maybe a separate question.) > > Are you asking if we intend to replace ND with efficient-ND, or are you > asking if ROLL networks will do no ND at all? > > In our analysis of the RPI/RH3, one of the things that came up is that wh= en > there are leafs which are plain 6lowpan nodes, which run 6775 (or classic > ND), that we have a problem. The issue is that the sending system needs = to > know whether or not the end node is a ROLL or 6775 node prior to sending. > While the DODAG root can know this, other nodes can not a-priori. The re= ason > is because an IPIP header needs to be inserted (or not), and the IPIP > header needs to be accurately addressed. > This is in the useofrpi ID, and we are trying to explain it in some diagr= ams. > > > > > -- > Michael Richardson > -on the road- > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you.