RFC 5595, "The Datagram Congestion Control Protocol (DCCP) Service Codes", September 2009Source of RFC: dccp (tsv)
Errata ID: 1891
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-22
Held for Document Update by: Lars Eggert
Date Held: 2011-03-01
Section 2.7, pg.10 says:
OLD: o It preserves the 4 lowest bits of the final bytes of the Service Code, which allows many common series of Service Codes to be mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2; Fooa and Foob would be assigned adjacent ports.
It should say:
NEW: o It preserves the 3 lowest bits of the final bytes of the Service ^^ Code, which allows many common series of Service Codes to be mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2; Fooa and Foob would be assigned adjacent ports.
Simply trying the full example shows that the statement is not
entirely correct. The quoted formula reveals that only the least
significant *3* bits are left unchanged (due to the '<<3'
operation on sc). It turns out that ranges of *8* contiguous
SC values are mapped to contiguous 8 port numbers but, depending
on the two least significant bits of sc, groups of 4 adjacent
ranges are shuffled around. More complicated patterns arise for
the next higher level of 4-clusters of range-groups, etc.
Thus, the situation is not hopeless for the indicated purpose,
but much more complicated than indicated in the RFC text.
I leave it as an exercise to the interested reader to figure
out the details for the size of range she is interested in.
A future revision of the RFC however should fix the text.