Routing Requirements for Urban Low-Power and Lossy Networks
draft-ietf-roll-urban-routing-reqs-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2009-04-02
|
05 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-04-02
|
05 | (System) | IANA Action state changed to No IC from In Progress |
2009-04-02
|
05 | (System) | IANA Action state changed to In Progress |
2009-04-02
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2009-04-02
|
05 | Cindy Morgan | IESG has approved the document |
2009-04-02
|
05 | Cindy Morgan | Closed "Approve" ballot |
2009-04-02
|
05 | Adrian Farrel | State Changes to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup by Adrian Farrel |
2009-04-02
|
05 | Adrian Farrel | Responsible AD has been changed to Adrian Farrel from David Ward |
2009-04-02
|
05 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel |
2009-03-31
|
05 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-03-30
|
05 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-05.txt |
2009-02-16
|
05 | Pasi Eronen | [Ballot discuss] [updated discuss for -04] Version -04 is a big improvement over -03, and addresses most of my concerns. The remaining concern is about … [Ballot discuss] [updated discuss for -04] Version -04 is a big improvement over -03, and addresses most of my concerns. The remaining concern is about distribution of "application layer information" by the routing protocol -- the document should say a bit more about this topic. Based on the earlier email discussions, it seems we have two quite different types of application layer information: one that's distributed by the routing protocol but consumed only by the applications (and does not influence the routing decision), and one that's also used in the network layer to influence routing decisions. An example of the former would be an application that asks the "routing module" for a list of nodes (IP addresses) that advertise capability "FOOBAR", and send its data to one of them (by putting it in the "Destination Address" field, not by influencing the routing decision in any other way). And at the other end, the application would ask the "routing module" to advertise capability "FOOBAR" for this node. One obvious use for this is topology-aware service discovery (finding an application instance "near me" and "near the shortest path towards the ultimate destination"), but probably there are other uses, too. An example of the latter would be distributing information about how the set of applications a node is running influences routing. Section 6.2 (last paragraph) suggest that the routing protocol should be able to e.g. route packets with DSCP value X via nodes that run application "FOOBAR" (or advertise capability "FOOBAR" via the routing protocol). Both of these may be reasonable requirements, but the document needs to be clearer about what the expected functionality is (the examples above might not be accurate, and it's possible I have misunderstood what the intent was), and say something about the expected interface between routing protocols and applications (since such interface is not really present in the current Internet). |
2009-02-15
|
04 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-04.txt |
2009-01-11
|
05 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-01-08
|
03 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-03.txt |
2008-12-19
|
05 | (System) | Removed from agenda for telechat - 2008-12-18 |
2008-12-18
|
05 | Cindy Morgan | State Changes to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer by Cindy Morgan |
2008-12-18
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-12-18
|
05 | Tim Polk | [Ballot comment] I also support Pasi's discuss. I believe the emphasis on lightweight security mechanisms could be appropriate for sensor reporting in some cases, but … [Ballot comment] I also support Pasi's discuss. I believe the emphasis on lightweight security mechanisms could be appropriate for sensor reporting in some cases, but I think that heavier mechanisms could be required for actuators and routers. The security considerations implies a least common denominator approach that will allow the admitted constraints of sensor components to dominate the correspondingly stronger components abilities and security requirements. |
2008-12-18
|
05 | Chris Newman | [Ballot comment] I support Pasi's Discuss. |
2008-12-18
|
05 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-18
|
05 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-12-18
|
05 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-12-18
|
05 | Ron Bonica | [Ballot comment] Also support Pasi's DISCUSS |
2008-12-18
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-18
|
05 | Jari Arkko | [Ballot comment] I support Pasi's Discuss. |
2008-12-18
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2008-12-18
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-12-18
|
05 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-roll-urban-routing-reqs, and I have major architectural concerns with the document. In particular, I was surprised to not find any … [Ballot discuss] I have reviewed draft-ietf-roll-urban-routing-reqs, and I have major architectural concerns with the document. In particular, I was surprised to not find any description of the assumed network architecture in this document. I had assumed this would be just another routing protocol for IPv6, but that doesn't seem to be the case (the document doesn't actually say much about the network protocol this routing is for -- it could be something else than IP completely!) For example, there are parts (for example, "groupcast") that would seem to imply that the network layer protocol is not IPv6 (or it's either heavily extended, or a new network protocol layer is inserted above the link layer and below IPv6). There are also text that suggests that routers are not just network layer elements (that forward packets based on the network layer headers), but also include application layer functionality (that interacts with the network layer and routing in rather unspecified ways). It's not clear whether this is intended to be just co-location of different layers in the same physical box, or largely a non-layered architecture where there is no well-defined separation between the network layer/routing and application level functionality (and parts of applications are essentially merged to the network layer/routing -- so the network layer wouldn't really be IPv6 in any sense, even if the on-the-wire headers looked similar). Moving from the overall architecture to security specifically, as noted in Sandra Murphy's SecDir review, the document needs to make a clearer distinction between the security requirements/mechanisms of applications using the urban LLNs, requirements/mechanisms of data forwarding, and requirements/mechanisms for routing (maintaining the state used for data forwarding). Much of the confusion here probably comes from the above-mentioned lack of well-defined layers in the network architecture; in non-layered network architures (e.g. "boxes connected by lines" or "beads on a string") the distinction between applications and network is less clear. Since it seems the expected modularization of functionality between layers (and in particular, functionality of the network layer protocol(s) and what "the network" looks like to applications) is somewhat different from normal Internet architecture and IPv6, it seems the WG should start with an architecture document before defining requirements for the routing protocol. That could describe at least the high-level view of how functions are modularized (layers or otherwise), how forwarding and addressing work (important for routing -- includes where state is needed, how network resources are allocated, etc.), what entities are named/addressed (e.g. what layer the addresses refer to), and -- perhaps most importantly -- what "the network" looks like to applications running "on top of it" (if it's a layered architecture -- if it's not, that's even more complex). |
2008-12-18
|
05 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-12-17
|
05 | Cullen Jennings | [Ballot comment] I'll be a bit surprised to see this have the security and reliability to control traffic lights. |
2008-12-17
|
05 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-12-16
|
05 | David Ward | State Changes to IESG Evaluation - Defer from IESG Evaluation by David Ward |
2008-12-14
|
05 | Russ Housley | [Ballot discuss] Based on the discussion that has followed the Gen_ART Review by Brian Carpenter, an updated document is needed, and it has not … [Ballot discuss] Based on the discussion that has followed the Gen_ART Review by Brian Carpenter, an updated document is needed, and it has not been posted yet. |
2008-12-12
|
05 | Russ Housley | [Ballot discuss] There has been no reply to the Last Call comments that were provided in the Gen_ART Review by Brian Carpenter. Please … [Ballot discuss] There has been no reply to the Last Call comments that were provided in the Gen_ART Review by Brian Carpenter. Please respond to those Last Call comments. I am especially interested in the reply to his comments about Section 6.2, where Brian says: > >> 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: for example, the >> analysis of traffic payload should encourage the enforcement of >> forwarding policies based upon aggregation capabilities for the sake >> of efficiency. > > The second half of this seems highly dubious to me. It encourages layer > violation, and this is known to be a performance issue for routers. > It will complicate the router, slow it down, and increase its cost and > power consumption. (It also won't work for encrypted payloads.) > There's no particular reason to believe that this would be a useful tradeoff, > since the aggregation is presumably in the upstream direction (away from > sensors and actuators, and towards servers) where the power and bandwidth > issues will presumably be less critical. > > If there is a desire to achieve traffic-based path selection, a simpler > mechanism than deep packet inspection should be used. I don't want to stray > too far into solutionism, but diffserv comes to mind. > > In any case this is written as an implementation requirement, not a > requirement on the routing protocol. The requirement stated in > "6.4. Support of Highly Directed Information Flows" seems much > closer to what is needed. |
2008-12-12
|
05 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-12-10
|
05 | David Ward | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by David Ward |
2008-12-06
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Sandra Murphy. |
2008-11-25
|
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-11-24
|
05 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2008-11-14
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2008-11-14
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2008-11-11
|
05 | Cindy Morgan | Last call sent |
2008-11-11
|
05 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2008-11-11
|
05 | David Ward | [Ballot Position Update] New position, Yes, has been recorded for David Ward |
2008-11-11
|
05 | David Ward | Ballot has been issued by David Ward |
2008-11-11
|
05 | David Ward | Created "Approve" ballot |
2008-11-11
|
05 | David Ward | Placed on agenda for telechat - 2008-12-18 by David Ward |
2008-11-11
|
05 | David Ward | Last Call was requested by David Ward |
2008-11-11
|
05 | David Ward | State Changes to Last Call Requested from Publication Requested by David Ward |
2008-11-11
|
05 | (System) | Ballot writeup text was added |
2008-11-11
|
05 | (System) | Last call text was added |
2008-11-11
|
05 | (System) | Ballot approval text was added |
2008-11-07
|
05 | Cindy Morgan | Proto-write-up for draft-ietf-roll-urban-routing-reqs-02 Intended status : Informational Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed … Proto-write-up for draft-ietf-roll-urban-routing-reqs-02 Intended status : Informational Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? JP Vasseur is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The I-D has been extensively discussed with the participation of several key members of the Working Group. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No specific issues. No IPR disclosures filed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Good consensus. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made, 0 errors. > (1.h) Has the document split its references into normative and > informative? Yes. Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. No downward reference. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document is informational with no IANA action request. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? The document does not specify any protocol extensions. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly which - given the limited radio range and the large number of nodes - requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless Routing Over Low power and Lossy networks (ROLL) solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of requirements reflecting these and further U-LLNs tailored characteristics. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Good support and no controversy. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? The document does not specify any protocol extensions. |
2008-11-07
|
05 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-10-21
|
02 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-02.txt |
2008-07-03
|
01 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-01.txt |
2008-04-16
|
00 | (System) | New version available: draft-ietf-roll-urban-routing-reqs-00.txt |