Skip to main content

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