As per Relevance of the word messages, we have this rfc below:
Network Working Group M.
Request for Comments: 1479 BBN Systems and
July 1993
Inter-Domain Policy Routing Protocol Specification: Version 1
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
We present the set of protocols and procedures that
Inter-Domain Policy Routing (IDPR). IDPR includes the
gateway protocol, the flooding protocol, the route server
protocol, the route generation procedure, the path control protocol
and the data message forwarding procedure
The following people have contributed to the protocols and
described in this document: Helen Bowns, Lee Breslau, Ken Carlberg
Isidro Castineyra, Deborah Estrin, Tony Li, Mike Little,
Obraczka, Sam Resheff, Martha Steenstrup, Gene Tsudik, and
Woodburn
Table of
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.
In this document, we specify the protocols and procedures
compose Inter-Domain Policy Routing (IDPR). The objective of IDPR
to construct and maintain routes between source and
administrative domains, that provide user traffic with the
requested within the constraints stipulated for the
transited. IDPR supports link state routing information
and route generation in conjunction with source specified
forwarding. Refer to [5] for a detailed justification of
approach to inter-domain policy routing
1.1. Domain
The IDPR architecture has been designed to accommodate
internetwork with tens of thousands of administrative
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
the services offered by, and the connectivity between,
domains. The intra-domain details - gateways, networks, and
traversed - of an inter-domain policy route are the responsibility
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
authority. The domain administrator defines service restrictions
transit traffic and service requirements for locally-
traffic, and selects the addressing schemes and routing
that apply within the domain. Within the Internet, each domain has
unique numeric identifier assigned by the Internet Assigned
Authority (IANA).
"Virtual gateways" (VGs) are the only IDPR-recognized
points between adjacent domains. Each virtual gateway is
collection of directly-connected "policy gateways" (see below) in
adjoining domains, whose existence has been sanctioned by
administrators of both domains. The domain administrators may
to establish more than one virtual gateway between the two domains
For each such virtual gateway, the two administrators together
a local numeric identifier, unique within the set of virtual
connecting the two domains. To produce a virtual gateway
unique within its domain, a domain administrator concatenates
mutually assigned local virtual gateway identifier together with
adjacent domain's identifier
Policy gateways (PGs) are the physical gateways within a
gateway. Each policy gateway enforces service restrictions on
transit traffic, as stipulated by the domain administrator,
forwards the traffic accordingly. Within a domain, two
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
in the same domain and are "adjacent" if they are in
domains. Adjacent policy gateways are "directly connected" if
only Internet-addressable entities attached to the connecting
are policy gateways in the virtual gateways. Note that
definition implies that not only point-to-point links but
networks may serve as direct connections between adjacent
gateways. The domain administrator assigns to each of its
gateways a numeric identifier, unique within that domain
A "domain component" is a subset of a domain's entities such that
entities within the subset are mutually reachable via intra-
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
consists of a single component, namely itself; however,
partitioned, a domain consists of multiple components. Each
component has an identifier, unique within the Internet, composed
the domain identifier together with the identifier of the lowest
numbered operational policy gateway within the component.
operational policy gateways within a domain component can
mutual reachability through intra-domain routing information. Hence
all such policy gateways can consistently determine, without
negotiation, which of them has the lowest number
1.2.
With IDPR, each domain administrator sets "transit policies"
dictate how and by whom the resources in its domain should be used
Transit policies are usually public, and they specify
services comprising
- Access restrictions: e.g., applied to traffic to or from
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
originating in its domain. Source policies are usually private,
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
IDPR comprises the following functions
- Collecting and distributing routing information including
transit policies and inter-domain connectivity
- Generating and selecting policy routes based on the
information distributed and on the source policies configured
requested
- Setting up paths across the Internet using the policy
generated
Steenstrup [Page 5]
RFC 1479 IDPR Protocol July 1993
- Forwarding messages across and between domains along
established paths
- Maintaining databases of routing information, inter-domain
routes, forwarding information, and configuration information
1.3.1. IDPR
Several different entities are responsible for performing the
functions
Policy gateways, the only IDPR-recognized connecting points
adjacent domains, collect and distribute routing information
participate in path setup, forward data messages along
paths, and maintain forwarding information databases
"Path agents", resident within policy gateways and within "
servers" (see below), act on behalf of hosts to select policy routes
to set up and manage paths, and to maintain forwarding
databases. Any Internet host can reap the benefits of IDPR, as
as there exists a path agent configured to act on its behalf and
means by which the host's messages can reach the path agent
Specifically, a path agent in one domain may be configured to act
behalf of hosts in another domain. In this case, the path agent'
domain is an IDPR "proxy" for the hosts' domain
Route servers maintain both the routing information database and
route database, and they generate policy routes using the
information collected and the source policies requested by the
agents. A route server may reside within a policy gateway, or it
exist as an autonomous entity. Separating the route server
from the policy gateways frees the policy gateways from both
memory intensive task of database (routing information and route
maintenance and the computationally intensive task of
generation. Route servers, like policy gateways, each have a
numeric identifier within their domain, assigned by the
administrator
Given the size of the current Internet, each policy gateway
perform the route server functions, in addition to its
forwarding functions, with little or no degradation in
forwarding performance. Aggregating the routing functions
policy gateways simplifies implementation; one need only install
protocols in policy gateways. Moreover, it simplifies
between routing functions, as all functions reside within each
gateway. As the Internet grows, the memory and processing
to perform the route server functions may become a burden for
policy gateways. When this happens, each domain administrator
Steenstrup [Page 6]
RFC 1479 IDPR Protocol July 1993
separate the route server functions from the policy gateways in
domain
"Mapping servers" maintain the database of mappings that
Internet names and addresses to domain identifiers. Each host
contained within a domain and is associated with a proxy domain
may be identical with the host's domain. The mapping server
will be integrated into the existing DNS name service (see [6])
will provide mappings between a host and its local and proxy domains
"Configuration servers" maintain the databases of
information that apply to IDPR entities within their domains
Configuration information for a given domain includes
policies (i.e., service offerings and restrictions), source
(i.e., service requirements), and mappings between local
entities and their names and addresses. The configuration
function will be integrated into a domain's existing
management system (see [7]-[8]).
1.4. Policy
The source and transit policies supported by IDPR are intended
accommodate a wide range of services available throughout
Internet. We describe the semantics of these policies,
on the access restriction aspects. To express these policies in
document, we have chosen to use a syntactic variant of Clark's
term notation [1]. However, we provide a more succinct syntax (
[7]) for actually configuring source and transit policies
1.4.1. Source
Each source policy takes the form of a collection of sets as follows
Applicable Sources and Destinations
{((H(1,1),s(1,1)),...,(H(1,f1),s(1,f1))),...,((H(n,1),s(n,1)),...,
(H(n,fn),s(n,fn)))}: The set of groups of source/
traffic flows to which the source policy applies. Each
flow group ((H(i,1),s(i,1)),...,(H(i,fi),s(i,fi))) contains a
of source hosts and corresponding destination hosts. Here, H(i,j
represents a host, and s(i,j), an element of {SOURCE
DESTINATION}, represents an indicator of whether H(i,j) is to
considered as a source or as a destination
Domain Preferences: {(AD(1),x(1)),...,(AD(m),x(m))}: The set
transit domains that the traffic flows should favor, avoid,
exclude. Here, AD(i) represents a domain, and x(i), an element
{FAVOR, AVOID, EXCLUDE}, represents an indicator of whether
including AD(i) are to be favored, avoided if possible,
Steenstrup [Page 7]
RFC 1479 IDPR Protocol July 1993
unconditionally excluded
UCI: The source user class for the traffic flows listed
RequestedServices: The set of requested services not related
access restrictions, i.e., service quality and monetary cost
When selecting a route for a traffic flow from a source host H(i,j
to a destination host H(i,k), where 1 < or = i < or = n and 1 < or =
j, k < or = fi, the path agent (see section 1.3.1) must honor
source policy such that
- For each domain, AD(p), contained in the route, AD(p) is not
to any AD(k), such that 1 < or = k < or = m and x(k) = EXCLUDE
- The route provides the services listed in the set
Services
1.4.2. Transit
Each transit policy takes the form of a collection of sets
follows
Source/Destination Access Restrictions
{((H(1,1),AD(1,1),s(1,1)),...,(H(1,f1),AD(1,f1),s(1,f1))),...,
((H(n,1),AD(n,1),s(n,1)),...,(H(n,fn),AD(n,fn),s(n,fn)))}: The
of groups of source and destination hosts and domains to which
transit policy applies. Each domain
((H(i,1),AD(i,1),s(i,1)),...,(H(i,fi),AD(i,fi),s(i,fi)))
a set of source and destination hosts and domains such that
transit domain will carry traffic from each source listed to
destination listed. Here, H(i,j) represents a set of hosts
AD(i,j) represents a domain containing H(i,j), and s(i,j),
subset of {SOURCE, DESTINATION}, represents an indicator
whether (H(i,j),AD(i,j)) is to be considered as a set of sources
destinations, or both
Temporal Access Restrictions: The set of time intervals during
the transit policy applies
User Class Access Restrictions: The set of user classes to which
transit policy applies
Offered Services: The set of offered services not related to
restrictions, i.e., service quality and monetary cost
Steenstrup [Page 8]
RFC 1479 IDPR Protocol July 1993
Virtual Gateway Access Restrictions
{((VG(1,1),e(1,1)),...,(VG(1,g1),e(1,g1))),...,((VG(m,1),e(m,1)),
gateways to which the transit policy applies. Each
gateway group ((VG(i,1),e(i,1)),...,(VG(i,gi),e(i,gi))) contains
set of domain entry and exit points such that each entry
gateway can reach (barring an intra-domain routing failure)
exit virtual gateway via an intra-domain route supporting
transit policy. Here, VG(i,j) represents a virtual gateway,
e(i,j), a subset of {ENTRY, EXIT}, represents an indicator
whether VG(i,j) is to be considered as a domain entry point,
point, or both
The domain advertising such a transit policy will carry traffic
any host in the set H(i,j) in AD(i,j) to any host in the set H(i,k
in AD(i,k), where 1 < or = i < or = n and 1 < or = j, k < or = fi
provided that
- SOURCE is an element of s(i,j).
- DESTINATION is an element of s(i,k).
- Traffic from H(i,j) enters the domain during one of the
in the set Temporal Access Restrictions
- Traffic from H(i,j) carries one of the user class identifiers
the set User Class Access Restrictions
- Traffic from H(i,j) enters via any VG(u,v) such that ENTRY is
element of e(u,v), where 1 < or = u < or = m and 1 < or = v < or =
gu
- Traffic to H(i,k) leaves via any VG(u,w) such that EXIT is
element of e(u,w), where 1 < or = w < or = gu
1.5. IDPR Message
There are two kinds of IDPR messages
- "Data messages" containing user data generated by hosts
- "Control messages" containing IDPR protocol-related
information generated by policy gateways and route servers
Within an internetwork, only policy gateways and route servers
able to generate, recognize, and process IDPR messages.
existence of IDPR is invisible to all other gateways and hosts
including mapping servers and configuration servers. Mapping
and configuration servers perform necessary but ancillary
Steenstrup [Page 9]
RFC 1479 IDPR Protocol July 1993
for IDPR, and thus they are not required to handle IDPR messages
An IDPR entity places IDPR-specific information in each IDPR
message it originates; this information is significant only
recipient IDPR entities. Using "encapsulation" across each domain
an IDPR message tunnels from source to destination across
internetwork through domains that may employ disparate intra-
addressing schemes and routing procedures
As an alternative to encapsulation, we had considered embedding
in IP, as a set of IP options. However, this approach has
following disadvantages
- Only domains that support IP would be able to participate in IDPR
domains that do not support IP would be excluded
- Each gateway, policy or other, in a participating domain would
least have to recognize the IDPR option, even if it did not
the IDPR protocols. However, most commercial routers are
optimized for IP options processing, and so IDPR message
might require significant processing at each gateway
- For some IDPR protocols, in particular path control, the
restrictions on IP options would preclude inclusion of all of
necessary protocol-related information
For these reasons, we decided against the IP option approach and
favor of encapsulation
An IDPR message travels from source to destination
consecutive policy gateways. Each policy gateway encapsulates
IDPR message with information, for example an IP header, that
enable the message to reach the next policy gateway. Note that
encapsulating header and the IDPR-specific information may
the message size beyond the MTU of the given domain. However
message fragmentation and reassembly is the responsibility of
protocol, for example IP, that encapsulates IDPR messages
transport between successive policy gateways; it is not currently
responsibility of IDPR itself
A policy gateway, when forwarding an IDPR message to a peer or
neighbor policy gateway, encapsulates the message in accordance
the addressing scheme and routing procedure of the given domain
indicates in the protocol field of the encapsulating header that
message is indeed an IDPR message. Intermediate gateways between
two policy gateways forward the IDPR message as they would any
message, using the information in the encapsulating header. Only
recipient policy gateway interprets the protocol field, strips
Steenstrup [Page 10]
RFC 1479 IDPR Protocol July 1993
the encapsulating header, and processes the IDPR message
A policy gateway, when forwarding an IDPR message to a directly
connected adjacent policy gateway, encapsulates the message
accordance with the addressing scheme of the entities within
virtual gateway and indicates in the protocol field of
encapsulating header that the message is indeed an IDPR message.
recipient policy gateway strips off the encapsulating header
processes the IDPR message. We recommend that the recipient
gateway perform the following validation check of the
header, prior to stripping it off. Specifically, the
policy gateway should verify that the source address and
destination address in the encapsulating header match the
policy gateway's address and its own address, respectively
Moreover, the recipient policy gateway should verify that the
arrived on the interface designated for the direct connection to
adjacent policy gateway. These checks help to ensure that
traffic that crosses domain boundaries does so only over
connections between adjacent policy gateways
Policy gateways forward IDPR data messages according to a
information database which maps "path identifiers", carried in
data messages, into next policy gateways. Policy gateways
IDPR control messages according to next policy gateways selected
the particular IDPR control protocols associated with the messages
Distinguishing IDPR data messages and IDPR control messages at
encapsulating protocol level, instead of at the IDPR protocol level
eliminates an extra level of dispatching and hence makes IDPR
forwarding more efficient. When encapsulated within IP messages
IDPR data messages and IDPR control messages carry the IP
numbers 35 and 38, respectively
1.5.1. IDPR Data Message
The path agents at a source domain determine which data
generated by local hosts are to be handled by IDPR. To each
message selected for IDPR handling, a source path agent prepends
following header
Steenstrup [Page 11]
RFC 1479 IDPR Protocol July 1993
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERSION | PROTO | LENGTH |
+---------------+---------------+-------------------------------+
| PATH ID |
| |
+---------------------------------------------------------------+
| TIMESTAMP |
+---------------------------------------------------------------+
| INT/AUTH |
| |
+---------------------------------------------------------------+
VERSION (8 bits) Version number for IDPR data messages,
equal to 1.
PROTO (8 bits) Numeric identifier for the protocol with which
process the contents of the IDPR data message. Only the path
at the destination interprets and acts upon the contents of the
field
LENGTH (16 bits) Length of the entire IDPR data message in bytes
PATH ID (64 bits) Path identifier assigned by the source's path
and consisting of the numeric identifier for the path agent's
(16 bits), the numeric identifier for the path agent's policy
(16 bits), and the path agent's local path identifier (32 bits) (
section 7.2).
TIMESTAMP (32 bits) Number of seconds elapsed since 1 January 1970
0:00 GMT
INT/AUTH (variable) Computed integrity/authentication value
dependent on the type of integrity/authentication requested
path setup
We describe the IDPR control message header in section 2.4.
1.6.
IDPR contains mechanisms for verifying message integrity and
authenticity and for protecting against certain types of denial
service attacks. It is particularly important to keep IDPR
messages intact, because they carry control information critical
the construction and use of viable policy routes between domains
All IDPR messages carry a single piece of information, referred to
Steenstrup [Page 12]
RFC 1479 IDPR Protocol July 1993
the "integrity/authentication value", which may be used not only
detect message corruption but also to verify the authenticity of
message source. In the Internet, the IANA will sanction the set
valid algorithms which may be used to compute
integrity/authentication values. This set may include
that perform only message integrity checks such as n-bit
redundancy checksums (CRCs), as well as algorithms that perform
message integrity and source authentication checks such as
hash functions of message contents
Each domain administrator is free to select
integrity/authentication algorithm, from the set specified by
IANA, for computing the integrity/authentication values contained
its domain's messages. However, we recommend that IDPR entities
each domain be capable of executing all of the valid algorithms
that an IDPR control message originating at an entity in one
can be properly checked by an entity in another domain
Each IDPR control message must carry a non-
integrity/authentication value. We recommend that control
integrity/authentication be based on a digital signature
applied to a one-way hash function, such as RSA applied to MD5 [17],
which simultaneously verifies message integrity and
authenticity. The digital signature may be based on either public
key or private-key cryptography. Our approach to digital
use in IDPR is based on the privacy-enhanced Internet electronic
service [13]-[15], already available in the Internet
We do not require that IDPR data messages carry a non-
integrity/authentication value. In fact, we recommend that a
layer (end-to-end) procedure, and not IDPR, assume responsibility
checking the integrity and authenticity of data messages, because
the amount of computation involved
1.7. Timestamps and Clock
Each IDPR message carries a timestamp (expressed in seconds
since 1 January 1970 0:00 GMT, following the UNIX precedent)
by the source IDPR entity, which serves to indicate the age of
message. IDPR entities use the absolute value of the timestamp
confirm that a message is current and use the relative
between timestamps to determine which message contains the
recent information
All IDPR entities must possess internal clocks that are
to some degree, in order for the absolute value of a
timestamp to be meaningful. The synchronization granularity
by IDPR is on the order of minutes and can be achieved manually
Steenstrup [Page 13]
RFC 1479 IDPR Protocol July 1993
Thus, a clock synchronization protocol operating among all
entities in all domains, while useful, is not necessary
An IDPR entity can determine whether to accept or reject a
based on the discrepancy between the message's timestamp and
entity's own internal clock time. Any IDPR message whose
lies outside of the acceptable range may contain stale or
information or may have been issued by a source whose internal
has lost synchronization with the message recipient's internal clock
Timestamp checks are required for control messages because of
consequences of propagating and acting upon incorrect
information. However, timestamp checks are discretionary for
messages but may be invoked during problem diagnosis, for example
when checking for suspected message replays
We note that none of the IDPR protocols contain explicit
for dealing with an exhausted timestamp space. As timestamp
exhaustion will not occur until well into the next century, we
timestamp space viability to outlast the IDPR protocols
1.8. Network
In this document, we do not describe how to configure and
IDPR. However, in this section, we do provide a list of the types
IDPR configuration information required. Also, in later
describing the IDPR protocols, we briefly note the types
exceptional events that must be logged for network management
Complete descriptions of IDPR entity configuration and IDPR
objects appear in [7] and [8] respectively
To participate in inter-domain policy routing, policy gateways
route servers within a domain each require configuration information
Some of the configuration information is specifically defined
the given domain, while some of the configuration information
universally defined throughout an internetwork. A
administrator determines domain-specific information, and in
Internet, the IANA determines globally significant information
To produce valid domain configurations, the domain
must receive the following global information from the IANA
- For each integrity/authentication type, the
identifier, syntax, and semantics. Available integrity
authentication types include but are not limited to
o public-key based signatures
o private-key based signatures
Steenstrup [Page 14]
RFC 1479 IDPR Protocol July 1993
o cyclic redundancy checksums
o no integrity/authentication
- For each user class, the numeric identifier, syntax,
semantics. Available user classes include but are not limited to
o federal (and if necessary, agency-specific such as NSF, DOD
DOE, etc.);
o research
o commercial
o support
- For each offered service that may be advertised in
policies, the numeric identifier, syntax, and semantics.
offered services include but are not limited to
o average message delay
o message delay variation
o average bandwidth available
o available bandwidth variation
o maximum transfer unit (MTU);
o charge per byte
o charge per message
o charge per unit time
- For each access restriction that may be advertised in
policies, the numeric identifier, syntax, and semantics.
access restrictions include but are not limited to
o Source and destination domains and host sets
o User classes
o Entry and exit virtual gateways
o Time of day
Steenstrup [Page 15]
RFC 1479 IDPR Protocol July 1993
- For each requested service that may appear within a path
message, the numeric identifier, syntax, and semantics.
requested services include but are not limited to
o maximum path life in minutes, messages, or bytes
o integrity/authentication algorithms to be used on
messages sent over the path
o upper bound on path delay
o minimum delay path
o upper bound on path delay variation
o minimum delay variation path
o lower bound on path bandwidth
o maximum bandwidth path
o upper bound on monetary cost
o minimum monetary cost path
In an internetwork-wide implementation of IDPR, the set of
configuration parameters and their syntax and semantics must
consistent across all participating domains. The IANA,
for establishing the full set of global configuration parameters
the Internet, relies on the cooperation of the administrators of
participating domains to ensure that the global parameters
consistent with the desired transit policies and user
requirements of each domain. Moreover, as the syntax and
of the global parameters affects the syntax and semantics of
corresponding IDPR software, the IANA must carefully define
global parameter so that it is unlikely to require
modification
The IANA provides configured global information to
servers in all domains participating in IDPR. Each
administrator uses the configured global information maintained
its configuration servers to develop configurations for each
entity within its domain. Each configuration server retains a
of the configuration for each local IDPR entity and also
the configuration to that entity using, for example, SNMP
Steenstrup [Page 16]
RFC 1479 IDPR Protocol July 1993
1.8.1. Policy Gateway
Each policy gateway must contain sufficient configuration
to perform its IDPR functions, which subsume those of the path agent
These include: validating IDPR control messages; generating
distributing virtual gateway connectivity and routing
messages to peer, neighbor, and adjacent policy gateways
distributing routing information messages to route servers in
domain; resolving destination addresses; requesting policy
from route servers; selecting policy routes and initiating
setup; ensuring consistency of a path with its domain's
policies; establishing path forwarding information; and
IDPR data messages along existing paths. The necessary
information includes the following
- For each integrity/authentication type, the numeric identifier
syntax, and semantics
- For each policy gateway and route server in the given domain,
numeric identifier and set of addresses or names
- For each virtual gateway connected to the given domain, the
identifier, the numeric identifiers for the constituent peer
gateways, and the numeric identifier for the adjacent domain
- For each virtual gateway of which the given policy gateway is
member, the numeric identifiers and set of addresses for
constituent adjacent policy gateways
- For each policy gateway directly-connected and adjacent to
given policy gateway, the local connecting interface
- For each local route server to which the given policy
distributes routing information, the numeric identifier
- For each source policy applicable to hosts within the given domain
the syntax and semantics
- For each transit policy applicable to the domain, the
identifier, syntax, and semantics
- For each requested service that may appear within a path
message, the numeric identifier, syntax, and semantics
- For each source user class, the numeric identifier, syntax,
semantics
Steenstrup [Page 17]
RFC 1479 IDPR Protocol July 1993
1.8.2. Route Server
Each route server must contain sufficient configuration
to perform its IDPR functions, which subsume those of the path agent
These include: validating IDPR control messages; deciphering
storing the contents of routing information messages;
routing information with other route servers and policy gateways
generating policy routes that respect transit policy restrictions
source service requirements; distributing policy routes to
agents in policy gateways; resolving destination addresses;
policy routes and initiating path setup; establishing path
information; and forwarding IDPR data messages along existing paths
The necessary configuration information includes the following
- For each integrity/authentication type, the numeric identifier
syntax, and semantics
- For each policy gateway and route server in the given domain,
numeric identifier and set of addresses or names
- For each source policy applicable to hosts within the given domain
the syntax and semantics
- For access restriction that may be advertised in
policies, the numeric identifier, syntax, and semantics
- For each offered service that may be advertised in transit policies
the numeric identifier, syntax, and semantics
- For each requested service that may appear within a path
message, the numeric identifier, syntax, and semantics
- For each source user class, the numeric identifier, syntax,
semantics
2. Control Message Transport
IDPR control messages convey routing-related information
directly affects the policy routes generated and the paths set
across the Internet. Errors in IDPR control messages can
widespread, deleterious effects on inter-domain policy routing,
so the IDPR protocols have been designed to minimize loss
corruption of control messages. For every control message
transmits, each IDPR protocol expects to receive notification as
whether the control message successfully reached the intended
recipient. Moreover, the IDPR recipient of a control message
verifies that the message appears to be well-formed, before acting
its contents
Steenstrup [Page 18]
RFC 1479 IDPR Protocol July 1993
All IDPR protocols use the Control Message Transport Protocol (CMTP),
a connectionless, transaction-based transport layer protocol,
communication with intended recipients of control messages.
retransmits unacknowledged control messages and applies integrity
authenticity checks to received control messages
There are three types of CMTP messages
DATAGRAM
Contains IDPR control messages
ACK: Positive acknowledgement in response to a DATAGRAM message
NAK: Negative acknowledgement in response to a DATAGRAM message
Each CMTP message contains several pieces of information supplied
the sender that allow the recipient to test the integrity
authenticity of the message. The set of integrity and
checks performed after CMTP message reception are
referred to as "validation checks" and are described in section 2.3.
When we first designed the IDPR protocols, CMTP as a
protocol did not exist. Instead, CMTP-equivalent functionality
embedded in each IDPR protocol. To provide a cleaner implementation
we later decided to provide a single transport protocol that could
used by all IDPR protocols. We originally considered using
existing transport protocol, but rejected this approach for
following reasons
- The existing reliable transport protocols do not provide all of
validation checks, in particular the timestamp and
checks, required by the IDPR protocols. Hence, if we were to
one of these protocols, we would still have to provide a
protocol on top of the transport protocol to force retransmission
IDPR messages that failed to pass the required validation checks
- Many of the existing reliable transport protocols are window-
and hence can result in increased message delay and resource
when, as is the case with IDPR, multiple independent messages
the same transport connection. A single message
transmission problems and requiring retransmission can prevent
window from advancing, forcing all subsequent messages to
behind it. Moreover, many of the window-based protocols do
support selective retransmission of failed messages but
require retransmission of not only the failed message but also
preceding messages within the window
For these reasons, we decided against using an existing
Steenstrup [Page 19]
RFC 1479 IDPR Protocol July 1993
protocol and in favor of developing CMTP
2.1. Message
At the transmitting entity, when an IDPR protocol is ready to issue
control message, it passes a copy of the message to CMTP; it
passes a set of parameters to CMTP for inclusion in the CMTP
and for proper CMTP message handling. In turn, CMTP converts
control message and associated parameters into a DATAGRAM
prepending the appropriate header to the control message. The
header contains several pieces of information to aid the
recipient in detecting errors (see section 2.4). Each IDPR
can specify all of the following CMTP parameters applicable to
control message
- IDPR protocol and message type
- Destination
- Integrity/authentication scheme
- Timestamp
- Maximum number of transmissions allotted
- Retransmission interval in microseconds
One of these parameters, the timestamp, can be specified directly
CMTP as the internal clock time at which the message is transmitted
However, two of the IDPR protocols, namely flooding and path control
themselves require message generation timestamps for proper
operation. Thus, instead of requiring CMTP to pass back a
to an IDPR protocol, we simplify the service interface between
and the IDPR protocols by allowing an IDPR protocol to specify
timestamp in the first place
Using the control message and accompanying parameters supplied by
IDPR protocol, CMTP constructs a DATAGRAM, adding to the
CMTP-specific parameters. In particular, CMTP assigns a "
identifier" to each DATAGRAM generated, which it uses to
acknowledgements with DATAGRAM messages. Each DATAGRAM
includes the received transaction identifier in its returned ACK
NAK, and each DATAGRAM sender uses the transaction identifier
match the received ACK or NAK with the original DATAGRAM
A single DATAGRAM, for example a routing information message or
path control message, may be handled by CMTP at many different
gateways. Within a pair of consecutive IDPR entities, the
Steenstrup [Page 20]
RFC 1479 IDPR Protocol July 1993
sender expects to receive an acknowledgement from the
recipient. However, only the IDPR entity that actually generated
original CMTP DATAGRAM has control over the transaction identifier
because that entity may supply a digital signature that covers
entire DATAGRAM. The intermediate policy gateways that transmit
DATAGRAM do not change the transaction identifier. Nevertheless,
each DATAGRAM recipient, the transaction identifier must
distinguish the DATAGRAM so that only one acknowledgement from
next DATAGRAM recipient matches the original DATAGRAM. Therefore
the transaction identifier must be globally unique
The transaction identifier consists of the numeric identifiers
the domain and IDPR entity (policy gateway or route server)
the original DATAGRAM, together with a 32-bit local
assigned by CMTP operating within that IDPR entity. We
implementing the 32-bit local identifier either as a simple
incremented for each DATAGRAM generated or as a fine
clock. The former always guarantees uniqueness of
identifiers; the latter guarantees uniqueness of
identifiers, provided the clock granularity is finer than the
possible interval between DATAGRAM generations and the clock
period is longer than the maximum round-trip delay to and from
internetwork destination
Before transmitting a DATAGRAM, CMTP computes the length of
entire message, taking into account the
integrity/authentication scheme, and then computes
integrity/authentication value over the whole message. CMTP
both of these quantities, which are crucial for checking
integrity and authenticity at the recipient, in the DATAGRAM header
After sending a DATAGRAM, CMTP saves a copy and sets an
retransmission timer, as directed by the IDPR protocol parameters
If the retransmission timer fires and CMTP has received neither
ACK nor a NAK for the DATAGRAM, CMTP then retransmits the DATAGRAM
provided this retransmission does not exceed the
allotment. Whenever a DATAGRAM exhausts its transmission allotment
CMTP discards the DATAGRAM, informs the IDPR protocol that
control message transmission was not successful, and logs the
for network management. In this case, the IDPR protocol may
resubmit its control message to CMTP, specifying an
destination, or discard the control message altogether
Steenstrup [Page 21]
RFC 1479 IDPR Protocol July 1993
2.2. Message
At the receiving entity, when CMTP obtains a DATAGRAM, it takes
of the following actions, depending upon the outcome of the
validation checks
- The DATAGRAM passes the CMTP validation checks. CMTP then
the DATAGRAM with enclosed IDPR control message, to the
IDPR protocol, which in turn applies its own integrity checks
the control message before acting on the contents. The
IDPR protocol, except in one case, directs CMTP to generate an
and return the ACK to the sender. That exception is the up/
protocol (see section 3.2) which determines reachability
adjacent policy gateways and does not use CMTP ACK messages
notify the sender of message reception. Instead, the up/
protocol messages themselves carry implicit information
message reception at the adjacent policy gateway. In the
where the recipient IDPR protocol directs CMTP to generate an ACK
it may pass control information to CMTP for inclusion in the ACK
depending on the contents of the original IDPR control message
For example, a route server unable to fill a request for
information may inform the requesting IDPR entity, through an
for the initial request, to place its request elsewhere
- The DATAGRAM fails at least one of the CMTP validation checks
CMTP then generates a NAK, returns the NAK to the sender,
discards the DATAGRAM, regardless of the type of IDPR
message contained in the DATAGRAM. The NAK indicates the nature
the validation failure and serves to help the sender
communication with the recipient. In particular, the CMTP
provides a mechanism for negotiation of IDPR version
integrity/authentication scheme, two parameters crucial
establishing communication between IDPR entities
Upon receiving an ACK or a NAK, CMTP immediately discards the
if at least one of the validation checks fails or if it is unable
locate the associated DATAGRAM. CMTP logs the latter event
network management. Otherwise, if all of the validation checks
and if it is able to locate the associated DATAGRAM, CMTP clears
associated retransmission timer and then takes one of the
actions, depending upon the message type
- The message is an ACK. CMTP discards the associated DATAGRAM
delivers the ACK, which may contain IDPR control information,
the appropriate IDPR protocol
- The message is a NAK. If the associated DATAGRAM has exhausted
transmission allotment, CMTP discards the DATAGRAM, informs
Steenstrup [Page 22]
RFC 1479 IDPR Protocol July 1993
appropriate IDPR protocol that the control message transmission
not successful, and logs the event for network management
Otherwise, if the associated DATAGRAM has not yet exhausted
transmission allotment, CMTP first checks its copy of the
against the failure indication contained in the NAK. If
DATAGRAM copy appears to be intact, CMTP retransmits the
and sets the associated retransmission timer. However, if
DATAGRAM copy appears to be corrupted, CMTP discards the DATAGRAM
informs the IDPR protocol that the control message transmission
not successful, and logs the event for network management
2.3. Message
On every CMTP message received, CMTP performs a set of
checks to test message integrity and authenticity. The order
which these tests are executed is important. CMTP must
determine if it can parse enough of the message to compute
integrity/authentication value. (Refer to section 2.4 for
description of CMTP message formats.) Then, CMTP must
compute the integrity/authentication value before checking
header information. An incorrect integrity/authentication
means that the message is corrupted, and so it is likely that
header information is incorrect. Checking specific header
before computing the integrity/authentication value not only
waste time and resources, but also may lead to incorrect diagnoses
a validation failure
The CMTP validation checks are as follows
- CMTP verifies that it can recognize both the control
version type contained in the header. Failure to recognize
one of these values means that CMTP cannot continue to parse
message
- CMTP verifies that it can recognize and accept
integrity/authentication type contained in the header;
integrity/authentication is not an acceptable type for CMTP
- CMTP computes the integrity/authentication value and verifies
it equals the integrity/authentication value contained in
header. For key-based integrity/authentication schemes, CMTP
use the source domain identifier contained in the CMTP header
index the correct key. Failure to index a key means that
cannot compute the integrity/authentication value
- CMTP computes the message length in bytes and verifies that
equals the length value contained in the header
Steenstrup [Page 23]
RFC 1479 IDPR Protocol July 1993
- CMTP verifies that the message timestamp is in the
range. The message should be no more recent than cmtp_new (300)
seconds ahead of the entity's current internal clock time. In
document, when we present an IDPR system configuration parameter
such as cmtp_new, we usually follow it with a recommended value
parentheses. The cmtp_new value allows some clock drift
IDPR entities. Moreover, each IDPR protocol has its own limit
the maximum age of its control messages. The message should be
less recent than a prescribed number of seconds behind
recipient entity's current internal clock time. Hence, each
protocol performs its own message timestamp check in addition
that performed by CMTP
- CMTP verifies that it can recognize the IDPR protocol
for the enclosed control message
Whenever CMTP encounters a failure while performing any of
validation checks, it logs the event for network management. If
failure occurs on a DATAGRAM, CMTP immediately generates a
containing the reason for the failure, returns the NAK to the sender
and discards the DATAGRAM message. If the failure occurs on an
or a NAK, CMTP discards the ACK or NAK message
2.4. CMTP Message
In designing the format of IDPR control messages, we have
to strike a balance between efficiency of link bandwidth usage
efficiency of message processing. In general, we have chosen
representations for IDPR information in order to minimize the
bandwidth consumed by IDPR-specific information. However, we
also organized IDPR information in order to speed message processing
which does not always result in minimum link bandwidth usage
To limit link bandwidth usage, we currently use fixed-
identifier fields in IDPR messages; domains, virtual 