rfc3219.txt

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

   There may be more than one LS peering relationship between
   neighboring domains.  The MultiExitDisc attribute is used by an LS to
   express a preference for one link between the domains over another
   link between the domains.  The use of the MultiExitDisc attribute is
   controlled by local policy.

4.3.4.9. Communities

   The Communities attribute is not a well-known attribute.  It is used
   to facilitate and simplify the control of routing information by
   grouping destinations into communities.

4.3.4.10. ITAD Topology

   The ITAD topology attribute is an intra-domain attribute that is used
   by LSs to indicate their intra-domain topology to other LSs in the
   domain.

4.3.4.11. ConvertedRoute

   The ConvertedRoute attribute indicates that an intermediate LS has
   altered the route by changing the route's Application Protocol.

4.4. KEEPALIVE Message Format

   TRIP does not use any transport-based keep-alive mechanism to
   determine if peers are reachable.  Instead, KEEPALIVE messages are
   exchanged between peers often enough as not to cause the Hold Timer
   to expire.  A reasonable maximum time between KEEPALIVE messages
   would be one third of the Hold Time interval.  KEEPALIVE messages
   MUST NOT be sent more than once every 3 seconds.  An implementation
   SHOULD adjust the rate at which it sends KEEPALIVE messages as a
   function of the negotiated Hold Time interval.



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


   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

   The KEEPALIVE message consists of only a message header and has a
   length of 3 octets.

4.5. NOTIFICATION Message Format

   A NOTIFICATION message is sent when an error condition is detected.
   The TRIP transport connection is closed immediately after sending a
   NOTIFICATION message.

   In addition to the fixed-size TRIP header, the NOTIFICATION message
   contains the following fields:

    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
   +---------------+---------------+--------------+----------------+
   |  Error Code   | Error Subcode |       Data... (variable)
   +---------------+---------------+--------------+----------------+

                Figure 10: TRIP NOTIFICATION Format

   Error Code:
   This 1-octet unsigned integer indicates the type of NOTIFICATION.
   The following Error Codes have been defined:

   Error Code       Symbolic Name               Reference
     1         Message Header Error             Section 6.1
     2         OPEN Message Error               Section 6.2
     3         UPDATE Message Error             Section 6.3
     4         Hold Timer Expired               Section 6.5
     5         Finite State Machine Error       Section 6.6
     6         Cease                            Section 6.7

   Error Subcode:
   This 1-octet unsigned integer provides more specific information
   about the nature of the reported error.  Each Error Code may have one
   or more Error Subcodes associated with it.  If no appropriate Error
   Subcode is defined, then a zero (Unspecific) value is used for the
   Error Subcode field.

   Message Header Error Subcodes:
      1  - Bad Message Length.
      2  - Bad Message Type.






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


   OPEN Message Error Subcodes:
      1  - Unsupported Version Number.
      2  - Bad Peer ITAD.
      3  - Bad TRIP Identifier.
      4  - Unsupported Optional Parameter.
      5  - Unacceptable Hold Time.
      6  - Unsupported Capability.
      7  - Capability Mismatch.

   UPDATE Message Error Subcodes:
      1 - Malformed Attribute List.
      2 - Unrecognized Well-known Attribute.
      3 - Missing Well-known Mandatory Attribute.
      4 - Attribute Flags Error.
      5 - Attribute Length Error.
      6 - Invalid Attribute.

   Data:
   This variable-length field is used to diagnose the reason for the
   NOTIFICATION.  The contents of the Data field depend upon the Error
   Code and Error Subcode.

   Note that the length of the data can be determined from the message
   length field by the formula:

            Data Length = Message Length - 5

   The minimum length of the NOTIFICATION message is 5 octets (including
   message header).

5. TRIP Attributes

   This section provides details on the syntax and semantics of each
   TRIP UPDATE attribute.

5.1. WithdrawnRoutes

   Conditional Mandatory: False.
   Required Flags: Well-known.
   Potential Flags: Link-State Encapsulation (when flooding).
   TRIP Type Code: 1

   The WithdrawnRoutes specifies a set of routes that are to be removed
   from service by the receiving LS(s).  The set of routes MAY be empty,
   indicated by a length field of zero.






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


5.1.1. Syntax of WithdrawnRoutes

   The WithdrawnRoutes Attribute encodes a sequence of routes in its
   value field.  The format for individual routes is given in Section
   5.1.1.1.  The WithdrawnRoutes Attribute lists the individual routes
   sequentially with no padding as shown in Figure 11.  Each route
   includes a length field so that the individual routes within the
   attribute can be delineated.

            +---------------------+---------------------+...
            |  WithdrawnRoute1... |  WithdrawnRoute2... |...
            +---------------------+---------------------+...

                 Figure 11: WithdrawnRoutes Format

5.1.1.1. Generic TRIP Route Format

   The generic format for a TRIP route is given in Figure 12.

    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
   +---------------+---------------+--------------+----------------+
   |       Address Family          |      Application Protocol     |
   +---------------+---------------+--------------+----------------+
   |            Length             |       Address (variable)     ...
   +---------------+---------------+--------------+----------------+

                Figure 12: Generic TRIP Route Format

   Address Family:
   The address family field gives the type of address for the route.
   Three address families are defined in this Section:

            Code              Address Family
            1                 Decimal Routing Numbers
            2                 PentaDecimal Routing Numbers
            3                 E.164 Numbers

   This document reserves address family code 0.  This document reserves
   address family codes 32768-65535 for vendor-specific applications
   (these are the codes with the first bit of the code value equal to
   1).  Additional address families may be defined in the future.
   Assignment of address family codes is controlled by IANA.  See
   Section 13 for IANA considerations.







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


   Application Protocol:
   The application protocol gives the protocol for which this routing
   table is maintained.  The currently defined application protocols
   are:

            Code              Protocol
            1                 SIP
            2                 H.323-H.225.0-Q.931
            3                 H.323-H.225.0-RAS
            4                 H.323-H.225.0-Annex-G

   This document reserves application protocol code 0.  This document
   reserves application protocol codes 32768-65535 for vendor-specific
   applications (these are the codes with the first bit of the code
   value equal to 1).  Additional application protocols may be defined
   in the future.  Assignment of application protocol codes is
   controlled by IANA.  See Section 13 for IANA considerations.

   Length:
   The length of the address field, in bytes.

   Address:
   This is an address (prefix) of the family type given by Address
   Family.  The octet length of the address is variable and is
   determined by the length field of the route.

5.1.1.2. Decimal Routing Numbers

   The Decimal Routing Numbers address family is a super set of all
   E.164 numbers, national numbers, local numbers, and private numbers.
   It can also be used to represent the decimal routing numbers used in
   conjunction with Number Portability in some countries/regions.  A set
   of telephone numbers is specified by a Decimal Routing Number prefix.
   Decimal Routing Number prefixes are represented by a string of
   digits, each digit encoded by its ASCII character representation.
   This routing object covers all phone numbers starting with this
   prefix.  The syntax for the Decimal Routing Number prefix is:

      Decimal-routing-number  = *decimal-digit
      decimal-digit           = DECIMAL-DIGIT
      DECIMAL-DIGIT           = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

   This DECIMAL Routing Number prefix is not bound in length.  This
   format is similar to the format for a global telephone number as
   defined in SIP [8] without visual separators and without the "+"
   prefix for international numbers.  This format facilitates efficient
   comparison when using TRIP to route SIP or H323, both of which use
   character based representations of phone numbers.  The prefix length



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


   is determined from the length field of the route.  The type of
   Decimal Routing Number (private, local, national, or international)
   can be deduced from the first few digits of the prefix.

5.1.1.3. PentaDecimal Routing Numbers

   This address family is used to represent PentaDecimal Routing Numbers
   used in conjunction with Number Portability in some
   countries/regions.  PentaDecimal Routing Number prefixes are
   represented by a string of digits, each digit encoded by its ASCII
   character representation.  This routing object covers all routing
   numbers starting with this prefix.  The syntax for the PentaDecimal
   Routing Number prefix is:

      PentaDecimal-routing-number   = *pentadecimal-digit
      pentadecimal-routing-digit    = PENTADECIMAL-DIGIT
      PENTADECIMAL-DIGIT            = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|
                                      "8"|"9"|"A"|"B"|"C"|"D"|"E"

   Note the difference in alphabets between Decimal Routing Numbers and
   PentaDecimal Routing Numbers.  A PentaDecimal Routing Number prefix
   is not bound in length.

   Note that the address family, which suits the routing numbers of a
   specific country/region depends on the alphabets used for routing
   numbers in that country/region.  For example, North American routing
   numbers SHOULD use the Decimal Routing Numbers address family,
   because their alphabet is limited to the digits "0" through "9".
   Another example, in most European countries routing numbers use the
   alphabet "0" through "9" and "A" through "E", and hence these
   countries SHOULD use the PentaDecimal Routing Numbers addres