3-1-tlv-format.body

This specification contains two parts: definition of a new BGP NLRI

that describes links, nodes, and prefixes comprising IGP link-state

information and definition of a new BGP path attribute (BGP-LS

attribute) that carries link, node, and prefix properties and

attributes, such as the link and prefix metric or auxiliary Router-

IDs of nodes, etc.

It is desirable to keep the dependencies on the protocol source of

this attribute to a minimum and represent any content in an IGP-

neutral way, such that applications that want to learn about a link-

state topology do not need to know about any OSPF or IS-IS protocol

specifics.

Information in the new Link-State NLRIs and attributes is encoded in

Type/Length/Value triplets. The TLV format is shown in Figure 4.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        Value (variable)                     //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 4: TLV Format

The Length field defines the length of the value portion in octets

(thus, a TLV with no value portion would have a length of zero). The

TLV is not padded to 4-octet alignment. Unrecognized types MUST be

preserved and propagated. In order to compare NLRIs with unknown

TLVs, all TLVs MUST be ordered in ascending order by TLV Type. If

there are more TLVs of the same type, then the TLVs MUST be ordered

in ascending order of the TLV value within the TLVs with the same

type by treating the entire Value field as an opaque hexadecimal

string and comparing leftmost octets first, regardless of the length

of the string. All TLVs that are not specified as mandatory are

considered optional.