Subject: [Roll] Nit: apps modified? longer-match term?

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Jul 2010 00:53:42 +0200

> o  Nodes provision routing table entries, for the destinations
> specified by the DIO, via their DODAG parents in the DODAG version.
> Nodes MUST provision a DODAG parent as a default route for the
> associated instance.  It is up to the end-to-end application to
> select the RPL instance to be associated to its traffic (should
> there be more than one instance)

1 - so end-to-end applications must be modified ro tun in an RPL
     network?
2 - so if there is only one instance then the applications must not be
     modified?

> and thus the default route upwards

So the default route upwards is associated to a traffic.

> when no longer-match exists.

No better route exists, maybe?

I don't understand "no longer-match exists": is it "shorter match
exists"? is it "longer-match does not exist"?

I do understand longest prefix match algorightms.  But many people
understand different things by this "longest prefix match" term, and it
deservers clarification, it precludes understanding the negative "no
longer-match exists".

If needed, I can discuss this term further, I am all ears.

In all cases, that last phrase is way too long.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Sun, 25 Jul 2010 11:22:46 +0200

> 2 - so if there is only one instance then the applications must not be

You could deploy a network with one RPLIntance equal to 0.

This text will be clarified in the next revision:

5.  RPL Instance

    Within a given LLN, there may be multiple, logically independent RPL
    instances.  A RPL node may belong to multiple RPL instances, and may
    act as a router in some and as a leaf in others.  This document
    describes how a single instance behaves.

    There are two types of RPL Instances: local and global.  RPL divides
    the RPLInstanceID space between Global and Local instances to allow
    for both coordinated and unilateral allocation of RPLInstanceIDs.
    Global RPL Instances are coordinated, have one or more DODAGs, and
    are typically long-lived.  Local RPL Instances are always a single
    DODAG whose singular root owns the corresponding DODAGID and
    allocates the Local RPLInstanceID in a unilateral manner.  Local RPL
    Instances can be used, for example, for constructing DODAGs in
    support of a future on-demand routing solution.  The mode of
    operation of Local RPL Instances is outside of the scope of this
    document and may be described in other companion specifications.

    The definition and provisioning of RPL instances are beyond the  
scope
    of this specification.  Those operations are expected to be such  
that
    data packets coming from the outside of the RPL network can
    unambiguously be associated to at least one RPL instance, and be
    safely routed over any instance that would match the packet.
    Information used to match a packet to a RPL instance can typically  
be
    taken from fields in the IPv6 header, like the flow label,
    differentiated services (DS) field, or destination address.

    Control and data packets within RPL network are tagged to
    unambiguously identify what RPL Instance they are part of.

    Every RPL control message has a RPLInstanceID field.  Some RPL
    control messages, when referring to a local RPLInstanceID as defined
    below, may also include a DODAGID.

    Data packet that flow within the RP network expose the RPLInstanceID
    in the RPL option that is specified in [I-D.hui-6man-rpl-option],  
and
    further described in Section 11.2.  For data packets coming from
    outside the RPL network, the RPLInstanceID is determined by the RPL
    network ingress router and placed in the RPL option that is added to
    the packet.

5.1.  RPL Instance ID

    A global RPLInstanceID MUST be unique to the whole LLN.  Mechanisms
    for allocating and provisioning global RPLInstanceID are out of  
scope
    for this document.  There can be up to 128 global instance in the
    whole network.  Local instances are always used in conjunction  
with a

Winter, et al.          Expires January 16, 2011               [Page 26]

Internet-Draft           draft-ietf-roll-rpl-11                July 2010

    DODAGID (which is either given explicitly or implicitly in some
    cases), and up 64 local instances per DODAGID can be supported.
    Local instances are allocated and managed by the node that owns the
    DODAGID, without any explicit coordination with other nodes, as
    further detailed below.

    A global RPLinstanceID is encoded in a RPLinstanceID field as
    follows:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |0|     ID      |  Global RPLinstanceID in 0..127
        +-+-+-+-+-+-+-+-+

         Figure 4: RPL Instance ID field format for global instances

    A local RPLInstanceID is autoconfigured by the node that owns the
    DODAGID and it MUST be unique for that DODAGID.  The DODAGID used to
    configure the local RPLInstanceID MUST be a reachable IPv6 address  
of
    the node, and MUST be used as an endpoint of all communications
    within that local instance.

    A local RPLinstanceID is encoded in a RPLinstanceID field as  
follows:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |1|D|   ID      |  Local RPLInstanceID in 0..63
        +-+-+-+-+-+-+-+-+

         Figure 5: RPL Instance ID field format for local instances

    The D flag in a Local RPLInstanceID is always set to 0 in RPL  
control
    messages.  It is used in data packets to indicate whether the  
DODAGID
    is the source or the destination of the packet.  If the D flag is  
set
    to 1 then the destination address of the IPv6 packet MUST be the
    DODAGID.  If the D flag is cleared then the source address of the
    IPv6 packet MUST be the DODAGID.

    For example, consider a node A that is the DODAG Root of a local RPL
    Instance, and has allocated a local RPLInstanceID.  By definition,
    all traffic traversing that local RPL Instance will either originate
    or terminate at node A. The DODAGID in this case will be the
    reachable IPv6 address of node A, and all traffic will contain the
    address of node A, thus the DODAGID, in either the source or
    destination address.  Thus the Local RPLInstanceID may indicate that
    the DODAGID is equivalent to either the source address or the
    destination address by setting the D flag appropriately.

Winter, et al.          Expires January 16, 2011               [Page 27]

Internet-Draft           draft-ietf-roll-rpl-11                July 2010

> So the default route upwards is associated to a traffic.

If your have multiple RPL instance, you have multiple default routes.
When steering your data packer to a RPL instance, it follows the routes
of the corresponding DODAG.

>> when no longer-match exists.

Because you can advertise specific routes in DIO, more specific than the
default route.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll