rfc1479.txt

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

Network Working Group                                     M. Steenstrup
Request for Comments: 1479                 BBN Systems and Technologies
                                                              July 1993


     Inter-Domain Policy Routing Protocol Specification: Version 1

Status of this Memo

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

Abstract

   We present the set of protocols and procedures that constitute
   Inter-Domain Policy Routing (IDPR).  IDPR includes the virtual
   gateway protocol, the flooding protocol, the route server query
   protocol, the route generation procedure, the path control protocol,
   and the data message forwarding procedure.

Contributors

   The following people have contributed to the protocols and procedures
   described in this document: Helen Bowns, Lee Breslau, Ken Carlberg,
   Isidro Castineyra, Deborah Estrin, Tony Li, Mike Little, Katia
   Obraczka, Sam Resheff, Martha Steenstrup, Gene Tsudik, and Robert
   Woodburn.

Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1. Domain Elements . . . . . . . . . . . . . . . . . . . . . . . 3
   1.2. Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   1.3. IDPR Functions. . . . . . . . . . . . . . . . . . . . . . . . 5
   1.3.1. IDPR Entities . . . . . . . . . . . . . . . . . . . . . . . 6
   1.4. Policy Semantics. . . . . . . . . . . . . . . . . . . . . . . 7
   1.4.1. Source Policies . . . . . . . . . . . . . . . . . . . . . . 7
   1.4.2. Transit Policies. . . . . . . . . . . . . . . . . . . . . . 8
   1.5. IDPR Message Encapsulation. . . . . . . . . . . . . . . . . . 9
   1.5.1. IDPR Data Message Format. . . . . . . . . . . . . . . . . .11
   1.6. Security. . . . . . . . . . . . . . . . . . . . . . . . . . .12
   1.7. Timestamps and Clock Synchronization. . . . . . . . . . . . .13
   1.8. Network Management. . . . . . . . . . . . . . . . . . . . . .14
   1.8.1. Policy Gateway Configuration. . . . . . . . . . . . . . . .17
   1.8.2. Route Server Configuration. . . . . . . . . . . . . . . . .18



Steenstrup                                                      [Page 1]

RFC 1479                     IDPR Protocol                     July 1993


   2. Control Message Transport Protocol. . . . . . . . . . . . . . .18
   2.1. Message Transmission. . . . . . . . . . . . . . . . . . . . .20
   2.2. Message Reception . . . . . . . . . . . . . . . . . . . . . .22
   2.3. Message Validation. . . . . . . . . . . . . . . . . . . . . .23
   2.4. CMTP Message Formats. . . . . . . . . . . . . . . . . . . . .24
   3. Virtual Gateway Protocol. . . . . . . . . . . . . . . . . . . .27
   3.1. Message Scope . . . . . . . . . . . . . . . . . . . . . . . .28
   3.1.1. Pair-PG Messages. . . . . . . . . . . . . . . . . . . . . .28
   3.1.2. Intra-VG Messages . . . . . . . . . . . . . . . . . . . . .29
   3.1.3. Inter-VG Messages . . . . . . . . . . . . . . . . . . . . .29
   3.1.4. VG Representatives. . . . . . . . . . . . . . . . . . . . .31
   3.2. Up/Down Protocol. . . . . . . . . . . . . . . . . . . . . . .31
   3.3. Implementation. . . . . . . . . . . . . . . . . . . . . . . .33
   3.4. Policy Gateway Connectivity . . . . . . . . . . . . . . . . .35
   3.4.1. Within a Virtual Gateway. . . . . . . . . . . . . . . . . .35
   3.4.2. Between Virtual Gateways. . . . . . . . . . . . . . . . . .37
   3.4.3. Communication Complexity. . . . . . . . . . . . . . . . . .40
   3.5. VGP Message Formats . . . . . . . . . . . . . . . . . . . . .41
   3.5.1. UP/DOWN . . . . . . . . . . . . . . . . . . . . . . . . . .41
   3.5.2. PG CONNECT. . . . . . . . . . . . . . . . . . . . . . . . .42
   3.5.3. PG POLICY . . . . . . . . . . . . . . . . . . . . . . . . .43
   3.5.4. VG CONNECT. . . . . . . . . . . . . . . . . . . . . . . . .44
   3.5.5. VG POLICY . . . . . . . . . . . . . . . . . . . . . . . . .45
   3.5.6. Negative Acknowledgements . . . . . . . . . . . . . . . . .46
   4. Routing Information Distribution. . . . . . . . . . . . . . . .47
   4.1. AD Representatives. . . . . . . . . . . . . . . . . . . . . .48
   4.2. Flooding Protocol . . . . . . . . . . . . . . . . . . . . . .48
   4.2.1. Message Generation. . . . . . . . . . . . . . . . . . . . .50
   4.2.2. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . .52
   4.2.3. Message Acceptance. . . . . . . . . . . . . . . . . . . . .52
   4.2.4. Message Incorporation . . . . . . . . . . . . . . . . . . .54
   4.2.5. Routing Information Database. . . . . . . . . . . . . . . .56
   4.3. Routing Information Message Formats . . . . . . . . . . . . .57
   4.3.1. CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . .57
   4.3.2. DYNAMIC . . . . . . . . . . . . . . . . . . . . . . . . . .62
   4.3.3. Negative Acknowledgements . . . . . . . . . . . . . . . . .63
   5. Route Server Query Protocol . . . . . . . . . . . . . . . . . .64
   5.1. Message Exchange. . . . . . . . . . . . . . . . . . . . . . .64
   5.2. Remote Route Server Communication . . . . . . . . . . . . . .65
   5.3. Routing Information . . . . . . . . . . . . . . . . . . . . .66
   5.4. Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . .67
   5.5. Route Server Message Formats. . . . . . . . . . . . . . . . .67
   5.5.1. ROUTING INFORMATION REQUEST . . . . . . . . . . . . . . . .67
   5.5.2. ROUTE REQUEST . . . . . . . . . . . . . . . . . . . . . . .68
   5.5.3. ROUTE RESPONSE. . . . . . . . . . . . . . . . . . . . . . .71
   5.5.4. Negative Acknowledgements . . . . . . . . . . . . . . . . .72
   6. Route Generation. . . . . . . . . . . . . . . . . . . . . . . .73
   6.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . . .74



Steenstrup                                                      [Page 2]

RFC 1479                     IDPR Protocol                     July 1993


   6.1.1. Implementation. . . . . . . . . . . . . . . . . . . . . . .75
   6.2. Route Directionality. . . . . . . . . . . . . . . . . . . . .78
   6.3. Route Database. . . . . . . . . . . . . . . . . . . . . . . .79
   6.3.1. Cache Maintenance . . . . . . . . . . . . . . . . . . . . .80
   7. Path Control Protocol and Data Message Forwarding Procedure . .80
   7.1. An Example of Path Setup. . . . . . . . . . . . . . . . . . .81
   7.2. Path Identifiers. . . . . . . . . . . . . . . . . . . . . . .84
   7.3. Path Control Messages . . . . . . . . . . . . . . . . . . . .85
   7.4. Setting Up and Tearing Down a Path. . . . . . . . . . . . . .87
   7.4.1. Validating Path Identifiers . . . . . . . . . . . . . . . .89
   7.4.2. Path Consistency with Configured Transit Policies . . . . .89
   7.4.3. Path Consistency with Virtual Gateway Reachability. . . . .91
   7.4.4. Obtaining Resources . . . . . . . . . . . . . . . . . . . .92
   7.4.5. Target Response . . . . . . . . . . . . . . . . . . . . . .93
   7.4.6. Originator Response . . . . . . . . . . . . . . . . . . . .93
   7.4.7. Path Life . . . . . . . . . . . . . . . . . . . . . . . .  94
   7.5. Path Failure and Recovery . . . . . . . . . . . . . . . . .  95
   7.5.1. Handling Implicit Path Failures . . . . . . . . . . . . .  96
   7.5.2. Local Path Repair . . . . . . . . . . . . . . . . . . . .  97
   7.5.3. Repairing a Path. . . . . . . . . . . . . . . . . . . . .  98
   7.6. Path Control Message Formats. . . . . . . . . . . . . . . . 100
   7.6.1. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 101
   7.6.2. ACCEPT. . . . . . . . . . . . . . . . . . . . . . . . . . 103
   7.6.3. REFUSE. . . . . . . . . . . . . . . . . . . . . . . . . . 103
   7.6.4. TEARDOWN. . . . . . . . . . . . . . . . . . . . . . . . . 104
   7.6.5. ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . 105
   7.6.6. REPAIR. . . . . . . . . . . . . . . . . . . . . . . . . . 106
   7.6.7. Negative Acknowledgements . . . . . . . . . . . . . . . . 106
   8. Security Considerations . . . . . . . . . . . . . . . . . . . 106
   9. Authors's Address . . . . . . . . . . . . . . . . . . . . . . 107
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

1.  Introduction

   In this document, we specify the protocols and procedures that
   compose Inter-Domain Policy Routing (IDPR).  The objective of IDPR is
   to construct and maintain routes between source and destination
   administrative domains, that provide user traffic with the services
   requested within the constraints stipulated for the domains
   transited.  IDPR supports link state routing information distribution
   and route generation in conjunction with source specified message
   forwarding.  Refer to [5] for a detailed justification of our
   approach to inter-domain policy routing.

1.1.  Domain Elements

   The IDPR architecture has been designed to accommodate an
   internetwork with tens of thousands of administrative domains



Steenstrup                                                      [Page 3]

RFC 1479                     IDPR Protocol                     July 1993


   collectively containing hundreds of thousands of local networks.
   Inter-domain policy routes are constructed using information about
   the services offered by, and the connectivity between, administrative
   domains.  The intra-domain details - gateways, networks, and links
   traversed - of an inter-domain policy route are the responsibility of
   intra-domain routing and are thus outside the scope of IDPR.

   An "administrative domain" (AD) is a collection of contiguous hosts,
   gateways, networks, and links managed by a single administrative
   authority.  The domain administrator defines service restrictions for
   transit traffic and service requirements for locally-generated
   traffic, and selects the addressing schemes and routing procedures
   that apply within the domain.  Within the Internet, each domain has a
   unique numeric identifier assigned by the Internet Assigned Numbers
   Authority (IANA).

   "Virtual gateways" (VGs) are the only IDPR-recognized connecting
   points between adjacent domains.  Each virtual gateway is a
   collection of directly-connected "policy gateways" (see below) in two
   adjoining domains, whose existence has been sanctioned by the
   administrators of both domains.  The domain administrators may agree
   to establish more than one virtual gateway between the two domains.
   For each such virtual gateway, the two administrators together assign
   a local numeric identifier, unique within the set of virtual gateways
   connecting the two domains.  To produce a virtual gateway identifier
   unique within its domain, a domain administrator concatenates the
   mutually assigned local virtual gateway identifier together with the
   adjacent domain's identifier.

   Policy gateways (PGs) are the physical gateways within a virtual
   gateway.  Each policy gateway enforces service restrictions on IDPR
   transit traffic, as stipulated by the domain administrator, and
   forwards the traffic accordingly.  Within a domain, two policy
   gateways are "neighbors" if they are in different virtual gateways.
   A single policy gateway may belong to multiple virtual gateways.
   Within a virtual gateway, two policy gateways are "peers" if they are
   in the same domain and are "adjacent" if they are in different
   domains.  Adjacent policy gateways are "directly connected" if the
   only Internet-addressable entities attached to the connecting medium
   are policy gateways in the virtual gateways.  Note that this
   definition implies that not only point-to-point links but also
   networks may serve as direct connections between adjacent policy
   gateways.  The domain administrator assigns to each of its policy
   gateways a numeric identifier, unique within that domain.

   A "domain component" is a subset of a domain's entities such that all
   entities within the subset are mutually reachable via intra-domain
   routes, but no entities outside the subset are reachable via intra-



Steenstrup                                                      [Page 4]

RFC 1479                     IDPR Protocol                     July 1993


   domain routes from entities within the subset.  Normally, a domain
   consists of a single component, namely itself; however, when
   partitioned, a domain consists of multiple components.  Each domain
   component has an identifier, unique within the Internet, composed of
   the domain identifier together with the identifier of the lowest-
   numbered operational policy gateway within the component.  All
   operational policy gateways within a domain component can discover
   mutual reachability through intra-domain routing information.  Hence,
   all such policy gateways can consistently determine, without explicit
   negotiation, which of them has the lowest number.

1.2.  Policy

   With IDPR, each domain administrator sets "transit policies" that
   dictate how and by whom the resources in its domain should be used.
   Transit policies are usually public, and they specify offered
   services comprising:

   -   Access restrictions: e.g., applied to traffic to or from certain
       domains or classes of users.

   -   Quality: e.g., delay, throughput, or error characteristics.

   -   Monetary cost: e.g., charge per byte, message, or unit time.

   Each domain administrator also sets "source policies" for traffic
   originating in its domain.  Source policies are usually private, and
   they specify requested services comprising:

   -   Access restrictions: e.g., domains to favor or avoid in routes.

   -   Quality: e.g., acceptable delay, throughput, and reliability.

   -   Monetary cost: e.g., acceptable session cost.

1.3.  IDPR Functions

   IDPR comprises the following functions:

   -   Collecting and distributing routing information including domain
       transit policies and inter-domain connectivity.

   -   Generating and selecting policy routes based on the routing
       information distributed and on the source policies configured or
       requested.

   -   Setting up paths across the Internet using the policy routes
       generated.