rfc3219.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,493 行 · 第 1/5 页

   Hold Time:
   This 2-octet unsigned integer indicates the number of seconds that
   the sender proposes for the value of the Hold Timer.  Upon receipt of
   an OPEN message, an LS MUST calculate the value of the Hold Timer by
   using the smaller of its configured Hold Time and the Hold Time
   received in the OPEN message.  The Hold Time MUST be either zero or
   at least three seconds.  An implementation MAY reject connections on
   the basis of the Hold Time.  The calculated value indicates the
   maximum number of seconds that may elapse between the receipt of
   successive KEEPALIVE and/or UPDATE messages by the sender.

   This 4-octet unsigned integer indicates the ITAD number of the
   sender.  The ITAD number must be unique for this domain within this
   confederation of cooperating LSs.




Rosenberg, et. al.          Standards Track                    [Page 11]

RFC 3219            Telephony Routing over IP (TRIP)        January 2002


   ITAD numbers are assigned by IANA as specified in Section 13.  This
   document reserves ITAD number 0.  ITAD numbers from 1 to 255 are
   designated for private use.

   TRIP Identifier:
   This 4-octet unsigned integer indicates the TRIP Identifier of the
   sender.  The TRIP Identifier MUST uniquely identify this LS within
   its ITAD.  A given LS MAY set the value of its TRIP Identifier to an
   IPv4 address assigned to that LS.  The value of the TRIP Identifier
   is determined on startup and MUST be the same for all peer
   connections.  When comparing two TRIP identifiers, the TRIP
   Identifier is interpreted as a numerical 4-octet unsigned integer.

   Optional Parameters Length:
   This 2-octet unsigned integer indicates the total length of the
   Optional Parameters field in octets.  If the value of this field is
   zero, no Optional Parameters are present.

   Optional Parameters:
   This field may contain a list of optional parameters, where each
   parameter is encoded as a <Parameter Type, Parameter Length,
   Parameter Value> triplet.

       0                   1                   2
       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
      +---------------+---------------+--------------+----------------+
      |       Parameter Type          |       Parameter Length        |
      +---------------+---------------+--------------+----------------+
      |                  Parameter Value (variable)...
      +---------------+---------------+--------------+----------------+

                    Figure 4: Optional Parameter Encoding

   Parameter Type:
   This is a 2-octet field that unambiguously identifies individual
   parameters.

   Parameter Length:
   This is a 2-octet field that contains the length of the Parameter
   Value field in octets.

   Parameter Value:
   This is a variable length field that is interpreted according to the
   value of the Parameter Type field.







Rosenberg, et. al.          Standards Track                    [Page 12]

RFC 3219            Telephony Routing over IP (TRIP)        January 2002


4.2.1. Open Message Optional Parameters

   This document defines the following Optional Parameters for the OPEN
   message.

4.2.1.1. Capability Information

   Capability Information uses Optional Parameter type 1.  This is an
   optional parameter used by an LS to convey to its peer the list of
   capabilities supported by the LS.  This permits an LS to learn of the
   capabilities of its peer LSs.  Capability negotiation is defined in
   Section 8.

   The parameter contains one or more triples <Capability Code,
   Capability Length, Capability Value>, where each triple is encoded as
   shown below:

    0                   1                   2
    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
   +---------------+---------------+--------------+----------------+
   |       Capability Code         |       Capability Length       |
   +---------------+---------------+--------------+----------------+
   |       Capability Value (variable)...
   +---------------+---------------+--------------+----------------+

           Figure 5:  Capability Optional Parameter

   Capability Code:
   Capability Code is a 2-octet field that unambiguously identifies
   individual capabilities.

   Capability Length:
   Capability Length is a 2-octet field that contains the length of the
   Capability Value field in octets.

   Capability Value:
   Capability Value is a variable length field that is interpreted
   according to the value of the Capability Code field.

   Any particular capability, as identified by its Capability Code, may
   appear more than once within the Optional Parameter.

   This document reserves Capability Codes 32768-65535 for vendor-
   specific applications (these are the codes with the first bit of the
   code value equal to 1).  This document reserves value 0.  Capability
   Codes (other than those reserved for vendor specific use) are
   controlled by IANA.  See Section 13 for IANA considerations.




Rosenberg, et. al.          Standards Track                    [Page 13]

RFC 3219            Telephony Routing over IP (TRIP)        January 2002


   The following Capability Codes are defined by this specification:

      Code           Capability
      1              Route Types Supported
      2              Send Receive Capability

4.2.1.1.1. Route Types Supported

   The Route Types Supported Capability Code lists the route types
   supported in this peering session by the transmitting LS.  An LS MUST
   NOT use route types that are not supported by the peer LS in any
   particular peering session.  If the route types supported by a peer
   are not satisfactory, an LS SHOULD terminate the peering session.
   The format for a Route Type is:

    0                   1                   2
    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
   +---------------+---------------+--------------+----------------+
   |        Address Family         |     Application Protocol      |
   +---------------+---------------+--------------+----------------+

            Figure 6: Route Types Supported Capability

   The Address Family and Application Protocol are as defined in Section
   5.1.1.  Address Family gives the address family being routed (within
   the ReachableRoutes attribute).  The application protocol lists the
   application for which the routes apply.  As an example, a route type
   for TRIP could be <E.164, SIP>, indicating a set of E.164
   destinations for the SIP protocol.

   The Route Types Supported Capability MAY contain multiple route types
   in the capability.  The number of route types within the capability
   is the maximum number that can fit given the capability length.  The
   Capability Code is 1 and the length is variable.

4.2.1.1.2. Send Receive Capability

   This capability specifies the mode in which the LS will operate with
   this particular peer.  The possible modes are: Send Only mode,
   Receive Only mode, or Send Receive mode.  The default mode is Send
   Receive mode.

   In Send Only mode, an LS transmits UPDATE messages to its peer, but
   the peer MUST NOT transmit UPDATE messages to that LS.  If an LS in
   Send Only mode receives an UPDATE message from its peer, it MUST
   discard that message, but no further action should be taken.





Rosenberg, et. al.          Standards Track                    [Page 14]

RFC 3219            Telephony Routing over IP (TRIP)        January 2002


   The UPDATE messages sent by an LS in Send Only mode to its intra-
   domain peer MUST include the ITAD Topology attribute whenever the
   topology changes.  A useful application of an LS in Send Only mode
   with an external peer is to enable gateway registration services.

   If a service provider terminates calls to a set of gateways it owns,
   but never initiates calls, it can set its LSs to operate in Send Only
   mode, since they only ever need to generate UPDATE messages, not
   receive them.  If an LS in Send Receive mode has a peering session
   with a peer in Send Only mode, that LS MUST set its route
   dissemination policy such that it does not send any UPDATE messages
   to its peer.

   In Receive Only mode, the LS acts as a passive TRIP listener.  It
   receives and processes UPDATE messages from its peer, but it MUST NOT
   transmit any UPDATE messages to its peer.  This is useful for
   management stations that wish to collect topology information for
   display purposes.

   The behavior of an LS in Send Receive mode is the default TRIP
   operation specified throughout this document.

   The Send Receive capability is a 4-octet unsigned numeric value.  It
   can only take one of the following three values:

      1 - Send Receive mode
      2 - Send only mode
      3 - Receive Only mode

   A peering session MUST NOT be established between two LSs if both of
   them are  in Send Only mode or if both of them are in Receive Only
   mode.  If a peer LS detects such a capability mismatch when
   processing an OPEN message, it MUST respond with a NOTIFICATION
   message and close the peer session.  The error code in the
   NOTIFICATION message must be set to "Capability Mismatch."

   An LS MUST be configured in the same Send Receive mode for all peers.

4.3. UPDATE Message Format

   UPDATE messages are used to transfer routing information between LSs.
   The information in the UPDATE packet can be used to construct a graph
   describing the relationships between the various ITADs.  By applying
   rules to be discussed, routing information loops and some other
   anomalies can be prevented.






Rosenberg, et. al.          Standards Track                    [Page 15]

RFC 3219            Telephony Routing over IP (TRIP)        January 2002


   An UPDATE message is used to both advertise and withdraw routes from
   service.  An UPDATE message may simultaneously advertise and withdraw
   TRIP routes.

   In addition to the TRIP header, the TRIP UPDATE contains a list of
   routing attributes as shown in Figure 7.  There is no padding between
   routing attributes.

         +------------------------------------------------+--...
         | First Route Attribute | Second Route Attribute |  ...
         +------------------------------------------------+--...

                    Figure 7: TRIP UPDATE Format

   The minimum length of an UPDATE message is 3 octets (there are no
   mandatory attributes in TRIP).

4.3.1. Routing Attributes

   A variable length sequence of routing attributes is present in every
   UPDATE message.  Each attribute is a triple <attribute type,
   attribute length, attribute value> of variable length.

       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
      +---------------+---------------+--------------+----------------+
      |  Attr. Flags  |Attr. Type Code|         Attr. Length          |
      +---------------+---------------+--------------+----------------+
      |                   Attribute Value (variable)                  |
      +---------------+---------------+--------------+----------------+

                    Figure 8: Routing Attribute Format

   Attribute Type is a two-octet field that consists of the Attribute
   Flags octet followed by the Attribute Type Code octet.

   The Attribute Type Code defines the type of attribute.  The basic
   TRIP-defined Attribute Type Codes are discussed later in this
   section.  Attributes MUST appear in the UPDATE message in numerical
   order of the Attribute Type Code.  An attribute MUST NOT be included
   more than once in the same UPDATE message.  Attribute Flags are used
   to control attribute processing when the attribute type is unknown.
   Attribute Flags are further defined in Section 4.3.2.