Subject: [Diffserv] FlowId and FlowIdOrAny

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2003 11:24:23 +0100

I changed the subject line and fixed the proposed TC. So here is where
I think we are. I have also reduced the CC list and I have added the
diffserv mailing list since diffserv folks should be in the loop I
think.

  FlowId TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION 
	"The flow identifier in an IPv6 header that may be used to
	 discriminate traffic flows."
      REFERENCE
	"RFC 2460"
      SYNTAX       Integer32 (0..1048575)

  FlowIdOrAny TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION 
	"The flow identifier in an IPv6 header that may be used to
	 discriminate traffic flows. The value of -1 is used to
	 indicate a wildcard, i.e. any value."
      REFERENCE
	"RFC 2460"
      SYNTAX       Integer32 (-1 | 0..1048575)

Open issues:

- Is the flow identifier the same as the flow label? I guess so. If
  this is true, then we should probably use the TC names FlowLabel
  and FlowLableOrAny and also change the wordings in the description
  clause.

- The name of the MIB modules which will contain these definitions.

- Since Fred kind of said that the diffServMultiFieldClfrFlowId
  object should have had a wildcard, can we agree that this is 
  actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny
  in the next revision of the DIFFSERV-MIB?

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Dan Grossman <[email-masked]>
Date: Tue, 21 Jan 2003 11:34:14 -0500

Um... since you're bringing the Diffserv folks into the middle of the conversation, would
it be possible to clue us in as to what we're talking about?
Thanks.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2003 18:19:21 +0100

>>>>> Dan Grossman writes:

Dan> Um... since you're bringing the Diffserv folks into the middle of
Dan> the conversation, would it be possible to clue us in as to what
Dan> we're talking about?  Thanks.

I can try - not sure I have the details right though since I joined
late in this as well.

I think the core of the story is that the FRAMEWORK-PIB currently
defined in draft-ietf-rap-frameworkpib-09.txt has the following
definition (in a generic filter):

   frwkIpFilterFlowId OBJECT-TYPE
       SYNTAX         Unsigned32 (0..1048575)
       STATUS         current
       DESCRIPTION
          "The flow identifier in an IPv6 header."
       ::= { frwkIpFilterEntry 7 }

Someone observed that this definition does not have a value to
indicate that this specific attribute is to be ignored when matching
packets. So it was suggested to change the definition. Note that
this document is sitting in 48 hour RFC review.

Some people observed this and checked the classifier definition in the
DIFFSERV-MIB. The DIFFSERV-MIB says:

diffServMultiFieldClfrFlowId OBJECT-TYPE
    SYNTAX         Unsigned32 (0..1048575)
    MAX-ACCESS     read-create
    STATUS         current
    DESCRIPTION
       "The flow identifier in an IPv6 header."
    ::= { diffServMultiFieldClfrEntry 8 }

It looks like this definition as well lacks a wildcard mechanism. Fred
Baker already wrote that he had one in mind but somehow if never got
into the mind. Note that the DIFFSERV-MIB is in RFC 3289 (Proposed
Standard).

Triggered by a query from Kwok, I checked the INTEGRATED-SERVICES-MIB
which has this definition:

    intSrvFlowFlowId OBJECT-TYPE
        SYNTAX      INTEGER (0..16777215)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
           "The flow ID that  this  sender  is  using,  if
           this  is  an IPv6 session."
       ::= { intSrvFlowEntry 11 }

This is published in RFC 2213 (Proposed Standard).

It would be nice to have common TCs in place for flow labels (or are
they called flow ids?) much in the same way we have common TCs for
DSCPs. And this is how we got to where we are (as far as I understand
the situation).

While we can't put common definitions in place while the ID is in 48
hours review, we hopefully can figure out a plan how we can address
this proliferation of different ways to represent flow lables when
documents are revised.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jan 2003 15:19:28 +0100

I found some more objects that seem to model a flow label. It turns
out that MIB authors are really creative...

draft-ietf-ipsp-ipsec-conf-mib-05.txt:

  ihfIPv6FlowLabel OBJECT-TYPE
      SYNTAX      OCTET STRING (SIZE(3))
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The IPv6 Flow Label that the packet must match against.
          This object is only used if ipv6FlowLabel is set in ihfType."
      ::= { ipHeaderFilterEntry 13 }

  They obviously have another mechanism to control whether the
  object participates in a match.

draft-ietf-rmonmib-sspm-mib-06.txt:

   sspmSourceProfileFlowLabel OBJECT-TYPE
       SYNTAX      Integer32 (0..1048575)     -- 20-bit range (0 to 0xfffff)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is  used to specify the Flow Label  in a IPv6
            packet (RFC 2460) to force special handling by the IPv6 routers for
            non-default quality-of-service.

            This object is meaningful only when sspmSourceDestAddressType is
            ipv6(2).  The value of this object defaults to zero if not
            set."
       DEFVAL { 0 }
       ::= { sspmSourceProfileEntry 7 }

  This object seems to actually control how the flow label looks like
  in packets coming from a synthetic traffic source.

Note that these objects are called flow label rather than flowid and
hence I did not find them the first time...

/js