Re: Clarification on object padding for Call-ID in RFC3474

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Richard,

RFC3474 documents procedures and protocol elements developed in another
SDO, and presents them as an Informational RFC.

It is an informational document issued primarily for IANA purposes. That
is, in order to reserve the necessary code points, it was desirable to
have an RFC. Arguably, this RFC did not need to include the encodings of
the various objects, and they are certainly only here in an informational
context.

I suggest that the best thing to do when you see deficiencies and issues
with the content of this RFC is to redirect your questions to the source
SDO (is it the OIF or the ITU-T?), but the editors of this RFC may be able
to help you.

Cheers,
Adrian

----- Original Message ----- 
From: "Rich Bradford (rbradfor)" <rbradfor@cisco.com>
To: <dpendarakis@tellium.com>; <zhiwlin@nyct.com>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, November 10, 2005 3:54 PM
Subject: Clarification on object padding for Call-ID in RFC3474


In RFC3474, section 4.1.1 describes the Call-ID.
The Call-ID has a variable-length field, the source LSR address toward
the end of the object as follows:

...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source LSR address                       |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local identifier  (continued)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the source LSR address length is defined its type:
      For Type=0x01, the source LSR address is 4 bytes
      For Type=0x02, the source LSR address is 16 bytes
      For Type=0x03, the source LSR address is 20 bytes
      For type=0x04, the source LSR address is 6 bytes
      For type=0x7f, the source LSR address has the length defined by
          the vendor

Since type=0x04 (and possibly type 0x7f) has a size that is not a
multiple of 4 bytes, the issue of padding and alignment is raised. Pad
bytes for objects are by default added to the end of an object and not
counted in the length (option A below). However, the diagram appears to
indicate 32-bit alignment of the Local identifier (Option B below).

So, for type=0x4, do we have:
A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes)
Or
B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes).

Thanks for your time,
 Rich