[Roll] Review of draft-ietf-roll-urban-routing-reqs-01
JP Vasseur <jvasseur@cisco.com> Thu, 21 August 2008 19:29 UTC
Return-Path: <roll-bounces@ietf.org>
X-Original-To: roll-archive@ietf.org
Delivered-To: ietfarch-roll-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC77A3A6831; Thu, 21 Aug 2008 12:29:15 -0700 (PDT)
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A773E3A6831 for <roll@core3.amsl.com>; Thu, 21 Aug 2008 12:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.945
X-Spam-Level:
X-Spam-Status: No, score=-4.945 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHo+BKPZweRp for <roll@core3.amsl.com>; Thu, 21 Aug 2008 12:28:53 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 25FD03A677E for <roll@ietf.org>; Thu, 21 Aug 2008 12:28:52 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.32,247,1217808000"; d="scan'208,217"; a="18331253"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2008 19:28:57 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7LJSv4J012521; Thu, 21 Aug 2008 15:28:57 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7LJSvbI001666; Thu, 21 Aug 2008 19:28:57 GMT
Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Aug 2008 15:28:57 -0400
Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Aug 2008 19:28:56 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Thu, 21 Aug 2008 21:28:54 +0200
From: JP Vasseur <jvasseur@cisco.com>
To: Mischa Dohler <mischa.dohler@cttc.es>, Tim Winter <tim.winter@ekasystems.com>, thomas.watteyne@orange-ftgroup.com, christian.jacquenet@orange-ftgroup.com, giyyarpuram.madhusudan@orange-ftgroup.com, gabriel.chegaray@orange-ftgroup.com, Dominique.Barthel@orange-ftgroup.com, roll@ietf.org
Message-ID: <C4D38E96.4FB46%jvasseur@cisco.com>
Thread-Topic: Review of draft-ietf-roll-urban-routing-reqs-01
Thread-Index: AckDxCXVl9keGlV0jkulakQaFFRIHQ==
Mime-version: 1.0
X-OriginalArrivalTime: 21 Aug 2008 19:28:57.0135 (UTC) FILETIME=[27B3FBF0:01C903C4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42268; t=1219346937; x=1220210937; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Review=20of=20draft-ietf-roll-urban-routing-req s-01 |Sender:=20 |To:=20Mischa=20Dohler=20<mischa.dohler@cttc.es>,=0A=20=20= 20=20=20=20=20=20Tim=20Winter=20<tim.winter@ekasystems.com>, =0A=20=20=20=20=20=20=20=20<thomas.watteyne@orange-ftgroup.c om>,=0A=20=20=20=20=20=20=20=20<christian.jacquenet@orange-f tgroup.com>,=0A=20=20=20=20=20=20=20=20<giyyarpuram.madhusud an@orange-ftgroup.com>,=0A=20=20=20=20=20=20=20=20<gabriel.c hegaray@orange-ftgroup.com>,=0A=20=20=20=20=20=20=20=20<Domi nique.Barthel@orange-ftgroup.com>,=20<roll@ietf.org>; bh=gd8z5KJaZnBvDCPTbA0jaB/l/CEHdKw6QuuBGrPNgps=; b=XiZDdtxjPn1Jm0vI3+pcftGYGnB4z4Gqv79FaeVIcGAWFKfEfp7YLO/rzM CVuAvXKACMfBYrhasNgjHqvlmA/eRNSRSTNgsSLo6eNpB2DJFj57bteisZIW lBtOqZ4jbC;
Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: "David E. Culler" <culler@cs.berkeley.edu>
Subject: [Roll] Review of draft-ietf-roll-urban-routing-reqs-01
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0990667676=="
Sender: roll-bounces@ietf.org
Errors-To: roll-bounces@ietf.org
Dear WG, As discussed in Dublin, the plan is to try to Last Call all the application-specific routing requirements document before end of September. Thus, please provide your detailed comments as soon as possible. Let me start my co-chair review with the Urban WSNs Routing Requirements, since (with the exception of the Mobility issue) the document is fairly stable. Comments are not by order of importance by in chronological order. Abstract ####### s/ for a wireless ROLL solution to be useful the protocol(s) ought to be energy-efficient, scalable, and autonomous/ the routing solution ought to be energy-efficient, scalable and autonomous. JP> You may want to use a different word than ³Autonomous². Do you refer to the ³self configuration² property ? Section 1 ####### * ³Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may be overlapping requirements derived from other application- specific requirements documents or as listed in [I-D.culler-rl2n-routing-reqs].² JP> Please remove this reference (ID abandoned) and insert reference to http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.txt , http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.tx t and http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r eqs-00.txt. * s/ Section 7 provides an overview of security considerations/ Section 7 provides an overview of routing security considerations Section 2 ######## * S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Low power and Lossy networks * Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. The definition is a little bit too vague. If used in the generic sense, no need to add it to the terminology section. Otherwise, it ought to be more specific. Section 3.1.1 ########### * S/ pre- planned location/ pre-planned location * What you refer to as a repeater is in fact a router. What I would suggest here is to reword this paragraph to indicate that some nodes are simple routers whereas other nodes are routers and also perform sensing/actuating task. Insert this paragraph after the Actuators and Sensors paragraphs. * ³Actuators may generally be mobile but are likely to be static in the majority of near-future roll-outs²: seems a bit contradictory. Don¹t you want to simply say that in a near-future the majority will be static? * ³Similar to the access points, actuator nodes do not suffer from any long-term resource constraints.² what about battery-operated actuators ? Section 3.1.4 ########### * ³pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals (e.g. Mercury), pH, radioactivity, etc;² => please expand acronym when first used. * ³These meters will be capable of advanced sensing functionalities such as measuring quality of service, providing granular interval data, or automating the detection of alarm conditions.² You may want to more accurately define the term ³quality of service² since as you know, we used that term of other purposes in IETF documents. * In addition they may be capable of advanced interactive functionalities such as remote service disconnect or remote demand reset.² => in this case, they are also acting as actuators. Section 3.2 ######### * s/ between one other/between each other * ³The network MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each.² JP> Thanks to make this ³MUST² routing-specific and move it to the requirements section. Section 3.3 ######### * RFID: expand acronym (Radio Frequency IDentification) and add to the terminology section * s/battery-powered nodes/battery powered nodes ³Sensor nodes are capable of forwarding data.² In other words, they can act as routers. No need to repeat this here. Section 3.4 ######### * ³2. packet errors due to medium access control;² JP> It is not really ³packet error² here. * Some available protocols may cause packets of neighbouring nodes to collide and hence cause a link outage.² JP> You may want to be more specific ³Some² ? * ³if ISM bands are to be used. For instance, if the 2.4GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the functioning of the U-LLN.² JP> Please expand acronym when first used and add to the terminology section (ISM, WLAN, ...) * Don¹t you want to say a few words about the varying BER leading to potentially even higher packet error loss ratio? Section 4.1 ######### * ³Pre-programmed MAC²: expand acronym * ³the autonomous organization² => self-organizing? * ³For example, nodes in urban sensor nodes SHOULD be able to:² => Several of the requirements that follow are nor routing specific. You may either want to change the SHOULD for a ³should² or just focus on the routing aspects and move them to the routing requirements section. * ³o Dynamically compute, select and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or the access point according to the service-specific and traffic-specific QoS, traffic engineering and security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g. a metropolitan area composed of clusters of sensors).² JP> You list important and stringent requirements here. Do you really need a routing algorithms capable of computing a path on a per QoS/service specific/... Basis ? Section 4.2 ######### * ³After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network. The former might be because a removed node is replaced or denser readings/actuations are needed or routing protocols report connectivity problems. ³ JP> Just to avoid any mis-interpretation when referring to routing problem, you mean that it may be desirable to inject to node because connectivity is not sufficient (lack of enough redundant path, ...) and not because of a routing issue per say. * ³Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or node-initiated disassociation ("phased-out"), where the node has enough time to inform the network about its removal.² JP> Again this is not a routing requirement. Unless you refer to the ability for the routing protocol to advertise to the rest of the network that it will be removed in order for the other node to re-compute their path and avoid traffic disruption (e.g. Similarly to what we do with the ISIS overload bit for example.) Is it what you mean ? If so, please clarify and move the routing requirement (SHOULD in capital letter to the routing requirement section). * ³The protocol(s) hence SHOULD support the pinpointing of problematic routing areas² JP> Could you clarify what you mean by ³pinpointing² since it could be interpreted in many ways? * The following section also requires some clarification you wrote: ³Furthermore, to inform the access point(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms SHOULD be supported.² JP> Are you explicitly requiring a Link State routing protocol or a routing protocol that provides information about link states or ... ? Note that a requirement document should stay solution agnostic and stay focus on the requirement. Is you requirement that any node needs to have visibility on other node characteristics with no attempt of aggregation? Section 4.3 ######### * ³The protocol(s) hence MUST support a large number of highly directional unicast flows from the sensing nodes or sensing clusters towards the access point or highly directed multicast or anycast flows from the nodes towards multiple access points.² JP> I think that what you mean is that the routing protocol MUST be optimized for Multipoint-to-Point traffic patterns (from sensors/actuators to Sink). As written, it is not clear whether you refer to it as a routing requirement ? This in fact what you wrote in section 6.5: ³To this end, the routing protocol(s) SHOULD support and utilize the fact of highly directed traffic flow to facilitate scalability and parameter constrained routing.² * s/ More generally, entire routing areas may be avoided at e.g. night but heavily used during the day when nodes are scavenging from sunlight/ More generally, entire routing areas may be avoided (e.g. at night) but heavily used during the day when nodes are scavenging from sunlight. JP> Doesn¹t this translate to the requirement for time-based routing (some form of policy routing) ? Section 4.4 ######### ³However, they are not very stringent where latencies SHOULD simply be sufficiently smaller than typical reporting intervals² JP> This is certainly true but not a routing requirement but a data plane requirement unless you refer to the ability to support QoS aware routing where each node may want to be able to compute different paths depending on the traffic requirements? * Move ³U-LLN network devices SHOULD support unicast and multicast routing capabilities² to the routing requirement section. You may want to leave the sentence here (without a SHOULD). * You use the term ³anycast² that has been discussed in the past, in particular in the context of the Home routing requirement document. I would suggest to define this term in the document, refer to RFC4291 or RFC1546, ... Section 4.5 ######### * ³An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most cases.² Then you provide the example of toxic gas level. This is one example where it might be desirable not to perform data aggregation/fusion and get multiple copies of the same message from different source to perform ³triangulation² and better localize the incident. * ³Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic. From this perspective, such nodes SHOULD inspect the contents of traffic payload for making routing and forwarding decisions: JP> This clarifies my previous question; you do refer to ability to compute different paths (with different characteristic). Note that the path selection process performed by the sender and potentially routers along the path is not strictly speaking a routing requirement. Move this requirement to the requirement section. * ³for example, the analysis of the traffic payload SHOULD be derived into aggregation capabilities for the sake of forwarding efficiency.² JP> Can you clarify what you mean here? * ³Delays and latencies are important; however, again, deliveries within seconds SHOULD suffice in most of the cases.² JP> Clearly not a routing requirement! Section 5 ######## * ³The network SHOULD take into consideration that different application traffic may require different priorities when traversing the network, and that some traffic may be more sensitive to latency.² JP> If by priorities you mean different routes with different characteristics then this is fine and already covered. If you refer to packet marking to provide different QoS in the data plane, this is not a routing requirement. * ³An U-LLN SHOULD support occasional large scale traffic flows from sensing nodes to access points, such as system-wide alerts. ³ and ³A node MUST be able to send its own alerts toward an access point while continuing to forward traffic on behalf of other devices who are also experiencing an alert condition. The network MUST be able to manage this sudden large traffic flow.² JP> Not routing requirements. Unless ... You require the ability to compute multiple paths and use all of them (symmetrical or asymmetrical routing ???) to spread out the traffic and limit network delays ? * You make an interesting reference to Smart Grid and DR/DSM. That said, you wrote ³The network SHOULD support internetworking, while giving attention to security implications of interfacing, for example, a home network with a utility U-LLN.² JP> Don¹t you mean that the routing protocol must be able to potentially interact via potential route redistribution with other routing protocol used in the Internet, should these two protocols not be identical ? Section 6 ######### * S/Current urban roll-outs are composed of sometimes more than a hundred nodes/ Current urban roll-outs are composed of sometimes more than one hundred nodes * ³ The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of to-be-specified size.² JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD with a to-be-specified size. Or did you mean ³configurable² ? * ³To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph.² JP> Please use the term ³node constrained based routing² * ³For the latter, the protocol(s) MUST support multi- and any-cast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network.² JP> You may want to more accurately define the term ³anycast² * ³ To mandate fully interoperable implementations, the routing protocol(s) proposed in U-LLN MUST support different devices and underlying technologies without compromising the operability and energy efficiency of the network.² JP> This requires clarification here. Do you mean that the routing protocol MUST support node constrained based routing? If so, it is already stated above. The support of different L1/L2 is a given (route over). * Section 6.8, as written, is not related to routing but data plane. Let me be more specific: * ³To this end, the routing protocol(s) SHOULD support minimum latency for alert reporting and time-critical data queries.² JP> The support of minimum latency path (data plane !) or the support for different metric path (control plane) ? * ³For regular data reporting, it SHOULD support latencies not exceeding a fraction of the smallest reporting interval. ³ JP> Not a routing requirement. Even if you are referring to a bound on the total path metric (the metric reflecting the delay in this case), this is an implementation issue. * ³Due to the different latency requirements, the routing protocol(s) SHOULD support the ability of dealing with different latency requirements. The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e.g. be latency).² JP> yes these are routing requirements although I would suggest to remove the first sentence, the requirement being captured in the second sentence. Section 7 ######### * ³As every network, U-LLNs are exposed to security threats that MUST be addressed.² JP> You cannot put a MUST here unless you list the routing security threats. * s/ potential security threats/ potential routing security threats => JP> Please use the term ³routing security² in place of ³security² throughout the section. * ³U-LLN networks SHOULD support mechanisms to preserve the confidentiality of the traffic that they forward. The U-LLN network SHOULD NOT prevent an application from employing additional confidentiality mechanisms.² JP> I do agree with the requirement but this is not a routing requirement. Could you focus on the routing security issues ? Or are you referring to the routing traffic confidentiality ? This is what you do right after: ³ The U-LLN MUST be protected against attempts to inject false or modified packets. For example, an attacker SHOULD be prevented from manipulating or disabling the routing function by compromising routing update messages. Moreover, it SHOULD NOT be possible to coerce the network into routing packets which have been modified in transit. To this end the routing protocol(s) MUST support message integrity.² JP> I do not see any reference to the type of routing attacks that could be performed on such networks because of the typical P2MP traffic pattern, extensive use of wireless links, ... JP> What I would suggest is to re-focus on the routing security issues with the Security expert that will get appointed. Reference section ############### The current reference section reads: 11.2. Informative References [I-D.brandt-roll-home-routing-reqs] Brandt, A., "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-brandt-roll-home-routing-reqs-01 (work in progress), May 2008. JP> Please update to draft-ietf-roll-home-routing-reqs and add the reference to draft-ietf-roll-indus-routing-reqs [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing Requirements for Low Power And Lossy Networks", draft-culler-rl2n-routing-reqs-01 (work in progress), July 2007. JP> This one can be removed. Last comment: please check that you expand acronyms when first used. Thanks. JP.
_______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- [Roll] Review of draft-ietf-roll-urban-routing-re… JP Vasseur
- Re: [Roll] Review of draft-ietf-roll-urban-routin… christian.jacquenet
- Re: [Roll] Review of draft-ietf-roll-urban-routin… Mischa Dohler
- Re: [Roll] Review of draft-ietf-roll-urban-routin… JP Vasseur