rfc3219.txt

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

Network Working Group                                       J. Rosenberg
Request for Comments: 3219                                   dynamicsoft
Category: Standards Track                                      H. Salama
                                                           Cisco Systems
                                                               M. Squire
                                                       Hatteras Networks
                                                            January 2002


                    Telephony Routing over IP (TRIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document presents the Telephony Routing over IP (TRIP).  TRIP is
   a policy driven inter-administrative domain protocol for advertising
   the reachability of telephony destinations between location servers,
   and for advertising attributes of the routes to those destinations.
   TRIP's operation is independent of any signaling protocol, hence TRIP
   can serve as the telephony routing protocol for any signaling
   protocol.

   The Border Gateway Protocol (BGP-4) is used to distribute routing
   information between administrative domains.  TRIP is used to
   distribute telephony routing information between telephony
   administrative domains.  The similarity between the two protocols is
   obvious, and hence TRIP is modeled after BGP-4.

Table of Contents

   1    Terminology and Definitions  ..............................   3
   2    Introduction  .............................................   4
   3    Summary of Operation  .....................................   5
   3.1  Peering Session Establishment and Maintenance  ............   5
   3.2  Database Exchanges  .......................................   6
   3.3  Internal Versus External Synchronization  .................   6
   3.4  Advertising TRIP Routes  ..................................   6



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


   3.5  Telephony Routing Information Bases  ......................   7
   3.6  Routes in TRIP  ...........................................   9
   3.7  Aggregation  ..............................................   9
   4    Message Formats  ..........................................  10
   4.1  Message Header Format  ....................................  10
   4.2  OPEN Message Format  ......................................  11
   4.3  UPDATE Message Format  ....................................  15
   4.4  KEEPALIVE Message Format   ................................  22
   4.5  NOTIFICATION Message Format   .............................  23
   5    TRIP Attributes   .........................................  24
   5.1  WithdrawnRoutes  ..........................................  24
   5.2  ReachableRoutes  ..........................................  28
   5.3  NextHopServer   ...........................................  29
   5.4  AdvertisementPath   .......................................  31
   5.5  RoutedPath  ...............................................  35
   5.6  AtomicAggregate   .........................................  36
   5.7  LocalPreference   .........................................  37
   5.8  MultiExitDisc  ............................................  38
   5.9  Communities  ..............................................  39
   5.10 ITAD Topology    ..........................................  41
   5.11 ConvertedRoute  ...........................................  43
   5.12 Considerations for Defining New TRIP Attributes   .........  44
   6    TRIP Error Detection and Handling   .......................  44
   6.1  Message Header Error Detection and Handling   .............  45
   6.2  OPEN Message Error Detection and Handling   ...............  45
   6.3  UPDATE Message Error Detection and Handling   .............  46
   6.4  NOTIFICATION Message Error Detection and Handling   .......  48
   6.5  Hold Timer Expired Error Handling   .......................  48
   6.6  Finite State Machine Error Handling   .....................  48
   6.7  Cease   ...................................................  48
   6.8  Connection Collision Detection   ..........................  48
   7    TRIP Version Negotiation   ................................  49
   8    TRIP Capability Negotiation   .............................  50
   9    TRIP Finite State Machine   ...............................  50
   10   UPDATE Message Handling   .................................  55
   10.1 Flooding Process   ........................................  56
   10.2 Decision Process   ........................................  58
   10.3  Update-Send Process   ..................................... 62
   10.4  Route Selection Criteria   ................................ 67
   10.5  Originating TRIP Routes   ................................. 67
   11    TRIP Transport   .......................................... 68
   12    ITAD Topology   ........................................... 68
   13    IANA Considerations  ...................................... 68
   13.1  TRIP Capabilities   ....................................... 68
   13.2  TRIP Attributes    ........................................ 69
   13.3  Destination Address Families   ............................ 69
   13.4  TRIP Application Protocols   .............................. 69
   13.5  ITAD Numbers   ............................................ 70



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


   14    Security Considerations   ................................. 70
   A1    Appendix 1: TRIP FSM State Transitions and Actions   ...... 71
   A2    Appendix 2: Implementation Recommendations   .............. 73
   Acknowledgments  ................................................ 75
   References  ..................................................... 75
   Intellectual Property Notice  ................................... 77
   Authors' Addresses  ............................................. 78
   Full Copyright Statement  ....................................... 79

1. Terminology and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   A framework for Telephony Routing over IP (TRIP) is described in [2].
   We assume the reader is familiar with the framework and terminology
   of [2].  We define and use the following terms in addition to those
   defined in [2].

   Telephony Routing Information Base (TRIB): The database of reachable
   telephony destinations built and maintained at an LS as a result of
   its participation in TRIP.

   IP Telephony Administrative Domain (ITAD): The set of resources
   (gateways, location servers, etc.) under the control of a single
   administrative authority.  End users are customers of an ITAD.

   Less/More Specific Route: A route X is said to be less specific than
   a route Y if every destination in Y is also a destination in X, and X
   and Y are not equal.  In this case, Y is also said to be more
   specific than X.

   Aggregation: Aggregation is the process by which multiple routes are
   combined into a single less specific route that covers the same set
   of destinations.  Aggregation is used to reduce the size of the TRIB
   being synchronized with peer LSs by reducing the number of exported
   TRIP routes.

   Peers: Two LSs that share a logical association (a transport
   connection).  If the LSs are in the same ITAD, they are internal
   peers.  Otherwise, they are external peers.  The logical association
   between two peer LSs is called a peering session.








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


   Telephony Routing Information Protocol (TRIP): The protocol defined
   in this specification.  The function of TRIP is to advertise the
   reachability of telephony destinations, attributes associated with
   the destinations, as well as the attributes of the path towards those
   destinations.

   TRIP destination: TRIP can be used to manage routing tables for
   multiple protocols (SIP, H323, etc.).  In TRIP, a destination is the
   combination of (a) a set of addresses (given by an address family and
   address prefix), and (b) an application protocol (SIP, H323, etc).

2. Introduction

   The gateway location and routing problem has been introduced in [2].
   It is considered one of the more difficult problems in IP telephony.
   The selection of an egress gateway for a telephony call, traversing
   an IP network towards an ultimate destination in the PSTN, is driven
   in large part by the policies of the various parties along the path,
   and by the relationships established between these parties.  As such,
   a global directory of egress gateways in which users look up
   destination phone numbers is not a feasible solution.  Rather,
   information about the availability of egress gateways is exchanged
   between providers, and subject to policy, made available locally and
   then propagated to other providers in other ITADs, thus creating
   routes towards these egress gateways.  This would allow each provider
   to create its own database of reachable phone numbers and the
   associated routes - such a database could be very different for each
   provider depending on policy.

   TRIP is an inter-domain (i.e., inter-ITAD) gateway location and
   routing protocol.  The primary function of a TRIP speaker, called a
   location server (LS), is to exchange information with other LSs.
   This information includes the reachability of telephony destinations,
   the routes towards these destinations, and information about gateways
   towards those telephony destinations residing in the PSTN.  The TRIP
   requirements are set forth in [2].

   LSs exchange sufficient routing information to construct a graph of
   ITAD connectivity so that routing loops may be prevented.  In
   addition, TRIP can be used to exchange attributes necessary to
   enforce policies and to select routes based on path or gateway
   characteristics.  This specification defines TRIP's transport and
   synchronization mechanisms, its finite state machine, and the TRIP
   data.  This specification defines the basic attributes of TRIP.  The
   TRIP attribute set is extendible, so additional attributes may be
   defined in future documents.





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


   TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) [3] and
   enhanced with some link state features, as in the Open Shortest Path
   First (OSPF) protocol [4], IS-IS [5], and the Server Cache
   Synchronization Protocol (SCSP) [6].  TRIP uses BGP's inter-domain
   transport mechanism, BGP's peer communication, BGP's finite state
   machine, and similar formats and attributes as BGP.  Unlike BGP
   however, TRIP permits generic intra-domain LS topologies, which
   simplifies configuration and increases scalability in contrast to
   BGP's full mesh requirement of internal BGP speakers.  TRIP uses an
   intra-domain flooding mechanism similar to that used in OSPF [4],
   IS-IS [5], and SCSP [6].

   TRIP permits aggregation of routes as they are advertised through the
   network.  TRIP does not define a specific route selection algorithm.

   TRIP runs over a reliable transport protocol.  This eliminates the
   need to implement explicit fragmentation, retransmission,
   acknowledgment, and sequencing.  The error notification mechanism
   used in TRIP assumes that the transport protocol supports a graceful
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   TRIP's operation is independent of any particular telephony signaling
   protocol.  Therefore, TRIP can be used as the routing protocol for
   any of these protocols, e.g., H.323 [7] and SIP [8].

   The LS peering topology is independent of the physical topology of
   the network.  In addition, the boundaries of an ITAD are independent
   of the boundaries of the layer 3 routing autonomous systems.  Neither
   internal nor external TRIP peers need to be physically adjacent.

3. Summary of Operation

   This section summarizes the operation of TRIP.  Details are provided
   in later sections.

3.1. Peering Session Establishment and Maintenance

   Two peer LSs form a transport protocol connection between one
   another.  They exchange messages to open and confirm the connection
   parameters, and to negotiate the capabilities of each LS as well as
   the type of information to be advertised over this connection.

   KeepAlive messages are sent periodically to ensure adjacent peers are
   operational.  Notification messages are sent in response to errors or
   special conditions.  If a connection encounters an error condition, a
   Notification message is sent and the connection is closed.




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


3.2. Database Exchanges

   Once the peer connection has been established, the initial data flow
   is a dump of all routes relevant to the new peer (In the case of an
   external peer, all routes in the LS's Adj-TRIB-Out for that external
   peer.  In the case of an internal peer, all routes in the Ext-TRIB
   and all Adj-TRIBs-In).  Note that the different TRIBs are defined in
   Section 3.5.

   Incremental updates are sent as the TRIP routing tables (TRIBs)
   change.  TRIP does not require periodic refresh of the routes.
   Therefore, an LS must retain the current version of all routing
   entries.