rsvpte_struct.h

实现了MPLS中的标签分发协议（LDP 3036 )的基本功能

   described in Section 2.3.2. This value must, by definition, be equal
   to or larger than the value of [m].


**********************************************************************/
typedef struct rsvpSenderTSpecObject_s {
    struct rsvpObjectHeader_s hdr;
} rsvpSenderTSpecObject_t;


#define RSVP_ADSPEC_CLASS 13
#define RSVP_ADSPEC_CTYPE_INTSRV 2
/**********************************************************************
      ADSPEC Class

      ADSPEC class = 13.

      o    Intserv ADSPEC object: Class = 13, C-Type = 2

   The basic ADSPEC format is shown below. The message header and the
   default general parameters fragment are always present. The fragments
   for Guaranteed or Controlled-Load service may be omitted if the
   service is not to be used by the RSVP session. Additional data
   fragments will be added if new services are defined.

       31           24 23            16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0 (a) |      reserved         |  Msg length - 1 (b)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Default General Parameters fragment (Service 1)  (c)       |
       |    (Always Present)                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Guaranteed Service Fragment (Service 2)    (d)             |
       |    (Present if application might use Guaranteed Service)      |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Controlled-Load Service Fragment (Service 5)  (e)          |
       |    (Present if application might use Controlled-Load Service) |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall message length not including header word
     (c, d, e) - Data fragments

3.3.2. Default General Characterization Parameters ADSPEC data fragment

   All RSVP ADSPECs carry the general characterization parameters
   defined in [RFC 2215].  Values for global or default general
   parameters (values which apply to the all services or the path
   itself) are carried in the per-service data fragment for service
   number 1, as shown in the picture above.  This fragment is always
   present, and always first in the message.

       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |    1  (c)     |x| reserved    |           8 (d)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    4 (e)      |    (f)        |           1 (g)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |        IS hop cnt (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |    6 (h)      |    (i)        |           1 (j)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Path b/w estimate  (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |     8 (k)     |    (l)        |           1 (m)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |        Minimum path latency (32-bit integer)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |     10 (n)    |      (o)      |           1 (p)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |      Composed MTU (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (c) - Per-Service header, service number 1 (Default General
           Parameters)
     (d) - Global Break bit ([RFC 2215], Parameter 2) (marked x) and
           length of General Parameters data block.
     (e) - Parameter ID, parameter 4 (Number-of-IS-hops param from
           [RFC 2215])
     (f) - Parameter 4 flag byte
     (g) - Parameter 4 length, 1 word not including header
     (h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
     (i) - Parameter 6 flag byte
     (j) - Parameter 6 length, 1 word not including header
     (k) - Parameter ID, parameter 8 (minimum path latency from [RFC
           2215])
     (l) - Parameter 8 flag byte
     (m) - Parameter 8 length, 1 word not including header
     (n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
     (o) - Parameter 10 flag byte
     (p) - Parameter 10 length, 1 word not including header

**********************************************************************/
typedef struct rsvpAdSpecObject_s {
    struct rsvpObjectHeader_s hdr;
} rsvpAdSpecObject_t;

/**********************************************************************

3.2. RSVP FLOWSPEC Object

   The RSVP FLOWSPEC object carries information necessary to make
   reservation requests from the receiver(s) into the network. This
   includes an indication of which QoS control service is being
   requested, and the parameters needed for that service.

   The QoS control service requested is indicated by the service_number
   in the FLOWSPEC's per-service header.

3.2.1 FLOWSPEC object when requesting Controlled-Load service

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting Controlled-Load service is shown below. Each of the TSpec
   fields is represented using the preferred concrete representation
   specified in the 'Invocation Information' section of [RFC 2211]. The
   value of 5 in the per-service header (field (c), below) indicates
   that Controlled-Load service is being requested.

        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |             7 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    5  (c)     |0| reserved    |             6 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall length (7 words not including header)
     (c) - Service header, service number 5 (Controlled-Load)
     (d) - Length of controlled-load data, 6 words not including
           per-service header
     (e) - Parameter ID, parameter 127 (Token Bucket TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including per-service
           header

   In this object, the TSpec parameters [r], [b], and [p] are set to
   reflect the traffic parameters of the receiver's desired reservation
   (the Reservation TSpec). The meaning of these fields is discussed
   fully in [RFC 2211]. Note that it is unlikely to make sense for the
   [p] term to be smaller than the [r] term.

   The maximum packet size parameter [M] should be set to the value of
   the smallest path MTU, which the receiver learns from information in
   arriving RSVP ADSPEC objects.  Alternatively, if the receiving
   application has built-in knowledge of the maximum packet size in use
   within the RSVP session, and this value is smaller than the smallest
   path MTU, [M] may be set to this value.  Note that requesting a value
   of [M] larger than the service modules along the data path can
   support will cause the reservation to fail. See section 2.3.2 for
   further discussion of the MTU value.

   The value of [m] can be chosen in several ways. Recall that when a
   resource reservation is installed at each intermediate node, the
   value used for [m] is the smaller of the receiver's request and the
   values in each sender's SENDER_TSPEC.

   If the application has a fixed, known minimum packet size, than that
   value should be used for [m]. This is the most desirable case.

   For a shared reservation style, the receiver may choose between two
   options, or pick some intermediate point between them.

      - if the receiver chooses a large value for [m], then the
      reservation will allocate less overhead for link-level headers.
      However, if a new sender with a smaller SENDER_TSPEC [m] joins the
      session later, an already-installed reservation may fail at that
      time.

      - if the receiver chooses a value of [m] equal to the smallest
      value which might be used by any sender, then the reservation will
      be forced to allocate more overhead for link-level headers.
      However it will not fail later if a new sender with a smaller
      SENDER_TSPEC [m] joins the session.

   For a FF reservation style, if no application-specific value is known
   the receiver should simply use the value of [m] arriving in each
   sender's SENDER_TSPEC for its reservation request to that sender.

**********************************************************************/
typedef struct rsvpFlowSpecObject_s {
    struct rsvpObjectHeader_s hdr;
} rsvpFlowSpecObject_t;

#define RSVP_POLICY_DATA_CLASS 14
#define RSVP_POLICY_DATA_CTYPE 1

/**********************************************************************
      POLICY_DATA Class

      POLICY_DATA class = 14.

      o    Type 1 POLICY_DATA object: Class = 14, C-Type = 1

           The contents of this object are for further study.

**********************************************************************/
typedef struct rsvpPolicyDataObject_s {
    struct rsvpObjectHeader_s hdr;
} rsvpPolicyDataObject_t;

#define RSVP_RESV_CONFIRM_CLASS 15
#define RSVP_RESV_CONFIRM_CTYPE_IPV4 1
#define RSVP_RESV_CONFIRM_CTYPE_IPV6 2

/**********************************************************************
      Resv_CONFIRM Class

      RESV_CONFIRM class = 15.

      o    IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |            IPv4 Receiver Address (4 bytes)            |
           +-------------+-------------+-------------+-------------+


      o    IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +            IPv6 Receiver Address (16 bytes)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
**********************************************************************/

typedef struct rsvpResvConfirmObject_s {
    struct rsvpObjectHeader_s hdr;
    union {
	u_int ipv4;
	u_char ipv6[16];
    } u;
} rsvpResvConfirmObject_t;


#define RSVP_LABEL_CLASS 16
#define RSVP_LABEL_CTYPE 1

/**********************************************************************

   LABEL class = 16, C_Type = 1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           (top label)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The contents of a LABEL is a single label, encoded in 4 octets.  Each
   generic MPLS label is an unsigned integer in the range 0 through
   1048575.  Generic MPLS labels and FR labels are encoded right aligned
   in 4 octets.  ATM labels are encoded with the VPI right justified in
   bits 0-15 and the VCI right justified in bits 16-31.

**********************************************************************/

typedef struct rsvpLabelObject_s {
    struct rsvpObjectHeader_s hdr;
    u_int label;
} rsvpLabelObject_t;

#define RSVP_LABEL_REQUEST_CLASS 19
#define RSVP_LABEL_REQUEST_CTYPE_GENERIC 1
#define RSVP_LABEL_REQUEST_CTYPE_ATM 2
#define RSVP_LABEL_REQUEST_CTYPE_FR 3

/**********************************************************************

   Label Request without Label Range Class = 19, C_Type = 1

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.


   Label Request with ATM Label Range Class = 19, C_Type = 2

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |             L3PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M| Res |    Minimum VPI        |      Minimum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |    Maximum VPI        |      Maximum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved (Res)

         This field is reserved.  It MUST be set to zero on transmission
         and MUST be ignored on receipt.

      L3PID

         an identifier of the layer 3 protocol using this path.
         Standard Ethertype values are used.

      M

         Setting this bit to one indicates that the node is capable of
         merging in the data plane

      Minimum VPI (12 bits)

         This 12 bit field specifies the lower bound of a block of
         Virtual Path Identifiers that is supported on the originating
         switch.  If the VPI is less than 12-bits it MUST be right
         justified in this field and preceding bits MUST be set to zero.