rfc3219.txt

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

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


   This document reserves Attribute Type Codes 224-255 for vendor-
   specific applications (these are the codes with the first three bits
   of the code equal to 1).  This document reserves value 0.  Attribute
   Type Codes (other than those reserved for vendor specific use) are
   controlled by IANA.  See Section 13 for IANA considerations.

   The third and the fourth octets of the route attribute contain the
   length of the attribute value field in octets.

   The remaining octets of the attribute represent the Attribute Value
   and are interpreted according to the Attribute Flags and the
   Attribute Type Code.  The basic supported attribute types, their
   values, and their uses are defined in this specification.  These are
   the attributes necessary for proper loop free operation of TRIP, both
   inter-domain and intra-domain.  Additional attributes may be defined
   in future documents.

4.3.2. Attribute Flags

   It is clear that the set of attributes for TRIP will evolve over
   time.  Hence it is essential that mechanisms be provided to handle
   attributes with unrecognized types.  The handling of unrecognized
   attributes is controlled via the flags field of the attribute.
   Recognized attributes should be processed according to their specific
   definition.

   The following are the attribute flags defined by this specification:
            Bit       Flag
            0         Well-Known Flag
            1         Transitive Flag
            2         Dependent Flag
            3         Partial Flag
            4         Link-state Encapsulated Flag

   The high-order bit (bit 0) of the Attribute Flags octet is the Well-
   Known Bit.  It defines whether the attribute is not well-known (if
   set to 1) or well-known (if set to 0).  Implementations are not
   required to support not well-known attributes, but MUST support
   well-known attributes.

   The second high-order bit (bit 1) of the Attribute Flags octet is the
   Transitive bit.  It defines whether a not well-known attribute is
   transitive (if set to 1) or non-transitive (if set to 0).  For well-
   known attributes, the Transitive bit MUST be zero on transmit and
   MUST be ignored on receipt.

   The third high-order bit (bit 2) of the Attribute Flags octet is the
   Dependent bit.  It defines whether a transitive attribute is



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


   dependent (if set to 1) or independent (if set to 0).  For well-known
   attributes and for non-transitive attributes, the Dependent bit is
   irrelevant, and MUST be set to zero on transmit and MUST be ignored
   on receipt.

   The fourth high-order bit (bit 3) of the Attribute Flags octet is the
   Partial bit.  It defines whether the information contained in the not
   well-known transitive attribute is partial (if set to 1) or complete
   (if set to 0).  For well-known attributes and for non-transitive
   attributes the Partial bit MUST be set to 0 on transmit and MUST be
   ignored on receipt.

   The fifth high-order bit (bit 4) of the Attribute Flags octet is the
   Link-state Encapsulation bit.  This bit is only applicable to certain
   attributes (ReachableRoutes and WithdrawnRoutes) and determines the
   encapsulation of the routes within those attributes.  If this bit is
   set, link-state encapsulation is used within the attribute.
   Otherwise, standard encapsulation is used within the attribute.  The
   Link-state Encapsulation technique is described in Section 4.3.2.4.
   This flag is only valid on the ReachableRoutes and WithdrawnRoutes
   attributes.  It MUST be cleared on transmit and MUST be ignored on
   receipt for all other attributes.

   The other bits of the Attribute Flags octet are unused.  They MUST be
   zeroed on transmit and ignored on receipt.

4.3.2.1. Attribute Flags and Route Selection

   Any recognized attribute can be used as input to the route selection
   process, although the utility of some attributes in route selection
   is minimal.

4.3.2.2. Attribute Flags and Route Dissemination

   TRIP provides for two variations of transitivity due to the fact that
   intermediate LSs need not modify the NextHopServer when propagating
   routes.  Attributes may be non-transitive, dependent transitive, or
   independent transitive.  An attribute cannot be both dependent
   transitive and independent transitive.

   Unrecognized independent transitive attributes may be propagated by
   any intermediate LS.  Unrecognized dependent transitive attributes
   MAY only be propagated if the LS is NOT changing the next-hop server.
   The transitivity variations permit some unrecognized attributes to be
   carried end-to-end (independent transitive), some to be carried
   between adjacent next-hop servers (dependent transitive), and other
   to be restricted to peer LSs (non-transitive).




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


   An LS that passes an unrecognized transitive attribute to a peer MUST
   set the Partial flag on that attribute.  Any LS along a path MAY
   insert a transitive attribute into a route.  If any LS except the
   originating LS inserts a new independent transitive attribute into a
   route, then it MUST set the Partial flag on that attribute.  If any
   LS except an LS that modifies the NextHopServer inserts a new
   dependent transitive attribute into a route, then it MUST set the
   Partial flag on that attribute.  The Partial flag indicates that not
   every LS along the relevant path has processed and understood the
   attribute.  For independent transitive attributes, the "relevant
   path" is the path given in the AdvertisementPath attribute.  For
   dependent transitive attributes, the relevant path consists only of
   those domains thru which this object has passed since the
   NextHopServer was last modified.  The Partial flag in an independent
   transitive attribute MUST NOT be unset by any other LS along the
   path.  The Partial flag in a dependent transitive attribute MUST be
   reset whenever the NextHopServer is changed, but MUST NOT be unset by
   any LS that is not changing the NextHopServer.

   The rules governing the addition of new non-transitive attributes are
   defined independently for each non-transitive attribute.  Any
   attribute MAY be updated by an LS in the path.

4.3.2.3. Attribute Flags and Route Aggregation

   Each attribute defines how it is to be handled during route
   aggregation.

   The rules governing the handling of unknown attributes are guided by
   the Attribute Flags.  Unrecognized transitive attributes are dropped
   during aggregation.  There should be no unrecognized non-transitive
   attributes during aggregation because non-transitive attributes must
   be processed by the local LS in order to be propagated.

4.3.2.4. Attribute Flags and Encapsulation

   Normally attributes have the simple format as described in Section
   4.3.1.  If the Link-state Encapsulation Flag is set, then the two
   additional fields are added to the attribute header as shown in
   Figure 9.











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


    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         |
   +---------------+---------------+--------------+----------------+
   |                  Originator TRIP Identifier                   |
   +---------------+---------------+--------------+----------------+
   |                        Sequence Number                        |
   +---------------+---------------+--------------+----------------+
   |                   Attribute Value (variable)                  |
   +---------------+---------------+--------------+----------------+

                 Figure 9: Link State Encapsulation

   The Originator TRIP ID and Sequence Number are used to control the
   flooding of routing updates within a collection of servers.  These
   fields are used to detect duplicate and old routes so that they are
   not further propagated to other LSs.  The use of these fields is
   defined in Section 10.1.

4.3.3. Mandatory Attributes

   There are no Mandatory attributes in TRIP.  However, there are
   Conditional Mandatory attributes.  A conditional mandatory attribute
   is an attribute, which MUST be included in an UPDATE message if
   another attribute is included in that message.  For example, if an
   UPDATE message includes a ReachableRoutes attribute, it MUST include
   an AdvertisementPath attribute as well.

   The three base attributes in TRIP are WithdrawnRoutes,
   ReachableRoutes, and ITAD Topology.  Their presence in an UPDATE
   message is entirely optional and independent of any other attributes.

4.3.4. TRIP UPDATE Attributes

   This section summarizes the attributes that may be carried in an
   UPDATE message.  Attributes MUST appear in the UPDATE message in
   increasing order of the Attribute Type Code.  Additional details are
   provided in Section 5.

4.3.4.1. WithdrawnRoutes

   This attribute lists a set of routes that are being withdrawn from
   service.  The transmitting LS has determined that these routes should
   no longer be advertised, and is propagating this information to its
   peers.





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


4.3.4.2. ReachableRoutes

   This attribute lists a set of routes that are being added to service.
   These routes will have the potential to be inserted into the Adj-
   TRIBs-In of the receiving LS and the route selection process will be
   applied to them.

4.3.4.3. NextHopServer

   This attribute gives the identity of the entity to which messages
   should be sent along this routed path.  It specifies the identity of
   the next hop server as either a host domain name or an IP address.
   It MAY optionally specify the UDP/TCP port number for the next hop
   signaling server.  If not specified, then the default port SHOULD be
   used.  The NextHopServer is specific to the set of destinations and
   application protocol defined in the ReachableRoutes attribute.  Note
   that this is NOT necessarily the address to which media (voice,
   video, etc.)  should be transmitted, it is only for the application
   protocol as given in the ReachableRoutes attribute.

4.3.4.4. AdvertisementPath

   The AdvertisementPath is analogous to the AS_PATH in BGP4 [3].  The
   attribute records the sequence of domains through which this
   advertisement has passed.  The attribute is used to detect when the
   routing advertisement is looping.  This attribute does NOT reflect
   the path through which messages following this route would traverse.
   Since the next-hop need not be modified by each LS, the actual path
   to the destination might not have to traverse every domain in the
   AdvertisementPath.

4.3.4.5. RoutedPath

   The RoutedPath attribute is analogous to the AdvertisementPath
   attribute, except that it records the actual path (given by the list
   of domains) *to* the destinations.  Unlike AdvertisementPath, which
   is modified each time the route is propagated, RoutedPath is only
   modified when the NextHopServer attribute changes.  Thus, it records
   the subset of the AdvertisementPath which signaling messages
   following this particular route would traverse.

4.3.4.6. AtomicAggregate

   The AtomicAggregate attribute indicates that a route may actually
   include domains not listed in the RoutedPath.  If an LS, when
   presented with a set of overlapping routes from a peer LS, selects a
   less specific route without selecting the more specific route, then
   the LS MUST include the AtomicAggregate attribute with the route.  An



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


   LS receiving a route with an AtomicAggregate attribute MUST NOT make
   the set of destinations more specific when advertising it to other
   LSs.

4.3.4.7. LocalPreference

   The LocalPreference attribute is an intra-domain attribute used to
   inform other LSs of the local LS's preference for a given route.  The
   preference of a route is calculated at the ingress to a domain and
   passed as an attribute with that route throughout the domain.  Other
   LSs within the same ITAD use this attribute in their route selection
   process.  This attribute has no significance between domains.

4.3.4.8. MultiExitDisc