Neighbor routers are configured to know if there is a level or
metalevel boundary between them, so that they can modify the RC level
and RC metalevel in a transmitted packet appropriately.
8.1 Exiting a Private Domain
The near-term Pip Architecture provides two methods of exit routing,
that is, routing inter-domain Pip packets from a source host to a
network service provider of a private domain [12,15]. In the first
method, called transit-driven exit routing, the source host leaves
the choice of provider to the routers. In the second method, called
host-driven exit routing, the source host explicitly chooses the
provider. In either method, it is possible to prevent internal
routers from having to carry external routing information. The exit
routing bit of the RC indicates which type of exit routing is in
effect.
With host-driven exit routing, it is possible for the host to choose
a provider through which the destination cannot be reached. In this
case, the host receives the appropriate PCMP Packet Not Delivered
message, and may either fallback on transit-driven exit routing or
choose a different provider.
When using transit-driven exit routing, there are two modes of
operation. The first, called destination-oriented, is used when the
routers internal to a domain have external routing information, and
the host has only one provider prefix. The second, called provider-
oriented, is used when the routers internal to a domain do not have
any external routing information or when the host has multiple
provider prefixes. (With IP, this case is called default routing.
In the case of IP, however, default routing does not allow an
intelligent choice of multiple exit points.)
With provider-oriented exit routing, the host arbitrarily chooses a
source Pip Address (and therefore, a provider). (Note that if the
Pip Header Server is tracking inter-domain routing, then it chooses
the appropriate provider.) If the host chooses the wrong provider,
then the border router will redirect the host to the correct provider
with a PCMP Provider Redirect message.
8.2 Intra-domain Networking
With intra-domain networking (where both source and destination are
in the private network), there are two scenarios of concern. In the
first, the destination address shares a providerPart with the source
address, and so the destination is known to be intra-domain even
before a packet is sent. In the second, the destination address does
not share a providerPart with the source address, and so the source
host doesn't know that the destination is reachable intra-domain.
Note that the first case is the most common, because the private
top-level number assignment acts as the common prefix even though it
isn't advertised globally (see section 4.1).
In the first case, the Pip Addresses in the Routing Directive need
not contain the providerPart. Rather, it contains only the address
part below the metalevel boundary. (A Pip Address in an FTIF Chain
always starts at a metalevel boundary).
For instance, if the source Pip Address is 1.2.3,4.5.6 and the
destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be
included for the destination address in the Routing Directive. (The
comma "," in the address indicates the metalevel boundary between
providerPart and subscriberPart.) The metalevel and level are set
accordingly.
In the second case, it is desirable to use the Pip Header Server to
determine if the destination is intra-domain or inter-domain. The
Pip Header Server can do this by monitoring intra-domain routing.
(This is done by having the Pip Header Server run the intra-domain
routing algorithm, but not advertise any destinations.) Thus, the Pip
Header Server can determine if the providerPart can be eliminated
from the address, as described in the last paragraph, or cannot and
must conform to the rules of exit routing as described in the
previous section.
If the Pip Header Server does not monitor intra-domain routing,
however, then the following actions occur. In the case of host-
driven exit routing, the packet will be routed to the stated
provider, and an external path will be used to reach an internal
destination. (The moral here is to not use host-driven exit routing
unless the Pip Header Server is privy to routing information, both
internal and external.)
In the case of transit-driven exit routing, the packet sent by the
host will eventually reach a router that knows that the destination
is intra-domain. This router will forward the packet towards the
destination, and at the same time send a PCMP Reformat Transit Part
message to the host. This message tells the host how much of the Pip
Address is needed to route the packet.
9. Pip Header Server
Two new components of the Pip Architecture are the Pip/IP Translator
and the Pip Header Server. The Pip/IP Translator is only used for
transition from IP to Pip, and otherwise would not be necessary. The
Pip Header Server, however, is a new architectural component.
The purpose of the Pip Header Server is to form a Pip Header. It is
useful to form the Pip header in a separate box because 1) in the
future (as policy routing matures, for instance), significant amounts
of information may be needed to form the Pip header--too much
information to distribute to all hosts, and 2) it won't be possible
to evolve all hosts at the same time, so the existence of a separate
box that can spoon-feed Pip headers to old hosts is necessary. (It
is impossible to guarantee that no modification of Pip hosts is
necessary for any potential evolution, but being able to form the
header in a server, and hand it to an outdated host, is a large step
in the right direction.)
(Note that policy routing architectures commonly if not universally
require the use of some kind of "route server" for calculating policy
routes. The Pip Header Server is, among other things, just this
server. Thus, the Pip Header Server does not so much result from the
fact that Pip itself is more complex than IP or other "IPv7"
proposals. Rather, the Pip Header Server reflects the fact that the
Pip Architecture has more functionality than ROAD architectures
supported by the simpler proposals.)
We note that for the near-term architecture hosts themselves will
by-and-large have the capability of forming Pip headers. The
exception to this will be the case where the Pip Header Server wishes
to monitor inter-domain routing to enhance provider selection. Thus,
the Pip Header Server role will be largely limited to evolution (see
section 16).
9.1 Forming Pip Headers
Forming a Pip header is more complex than forming an IP header
because there are many more choices to make. At a minimum, one of
multiple Pip Addresses (both source and destination) must be chosen
[14]. In the near future, it will also be necessary to choose a TOS.
After DNS information about the destination has been received, the
the following information is available to the Pip header formation
function.
1. From DNS: The destination's providers (either directly connected
or nearby enough to justify making a policy decision about), and
the names, types, and access restrictions of those providers.
2. From the source host: The application type (and thus, the desired
service), and the user access restriction classes.
3. From local configuration: The source's providers, and the names,
types, and access restrictions of those providers.
4. Optionally from inter-domain routing: The routes chosen by
inter-domain to all top level providers. (Note that inter-domain
routing in the Pip near-term architecture is path-vector.
Because of this, the Pip Header Server does not obtain enough
information from inter-domain routing to form a policy route.
When the technology to do this matures, it can be installed into
Pip Header Servers.)
The inter-domain routing information is optional. If it is used,
then probably a Pip Header Server is necessary, to limit this
information to a small number of systems.
There may also be arbitrary policy information available to the Pip
header formation function. This architecture does not specify any
such information.
The Pip header formation function then goes through a process of
forming an ordered list of source/destination Pip Addresses to use.
The ordering is based on knowledge of the application service
requirements, the service provided by the source providers, guesses
or learned information about the service provided by the destination
providers or by source/destination provider pairs, and the cost of
using source providers to reach destination providers. It is assumed
that the sophistication of forming the ordered list will grow as
experienced is gained with internet commercialization and real-time
services.
The Pip Header formation function then returns the ordered pairs of
source and destination addresses to the source host in the PHP
response message, along with an indication of what kind of exit
routing to use with each pair. Any additional information, such as
PDN Address, is also returned. With this information, the source
host can now establish communications and properly respond to PCMP
messages. Based on information received from PCMP messages,
particularly PCMP Packet Not Delivered messages but also Mobile Host
messages, the host is able to choose appropriately from the ordered
list.
Note that if Pip evolves to the point where the Transit Part of the
Pip header is no longer compatible with the current Transit Part, and
the querying host has not been updated to understand the new Transit
Part, then the PHP response message contains a bit map of the Transit
Part. The host puts this bit map into the Transit Part of the
transmitted Pip header even though it does not understand the
semantics of the Transit Part. The Host Version field indicates to
the Pip Header Server what kinds of transit parts the host can
understand.
9.2 Pip Header Protocol (PHP)
The Pip Header Protocol (PHP) is a simple query/response protocol
used to exchange information between the Pip host and the Pip Header
Server [6]. In the query, the Pip host includes (among other things)
the domain name of the destination it wishes to send Pip packets to.
(Thus, the PHP query serves as a substitute for the DNS query.)
The PHP query also contains 1) User Access Restriction Classes, 2)
Application Types, and 3) host version. The host version tells the
Pip Header Server what features are installed in the host. Thus, the
Pip Header Server is able to determine if the host can format its own
Pip header based on DNS information, or whether the Pip Header Server
needs to do it on behalf of the host. In the future, the PHP query
will also contain desired TOS (possibly in lieu of Application Type).
(Note that this information could come from the application. Thus,
the application interface to PHP (the equivalent of gethostbyname())
must pass this information.)
9.3 Application Interface
In order for a Pip host to generate the information required in the
PHP query, there must be a way for the application to convey the
information to the PHP software. The host architecture for doing
this is as follows.
A local "Pip Header Client" (the source host analog to the Pip Header
Server) is called by the application (instead of the current
gethostbyname()). The application provides the Pip Header Client
with either the destination host domain name or the destination host
Pip ID, and other pertinent information such as user access
restriction class and TOS. The Pip Header Client, if it doesn't have
the information cached locally, queries the Pip Header Server and
receives an answer. (Remember that the Pip Header Server can be co-
resident with the host.)
Once the Pip Header Client has determined what the Pip header(s) are,
it assigns a local handle to the headers, returns the handle to the
application, and configures the Pip packet processing engine with the
handle and related Pip Headers. The application then issues packets
to the Pip layer (via intervening layers such as transport) using the
local handle.
10. Routing Algorithms in Pip
This section discusses the routing algorithm for use with
(hierarchical) Pip Addresses.
The architecture for operating routing algorithms in Pip reflects the
clean partitioning of routing contexts in the Pip header. Thus,
routing in the Pip architecture is nicely modularized.
Within the Hierarchical Pip Address, there are multiple hierarchical
levels. Wherever two routers connect, or two levels interface
(either in a single router or between routers), two decisions must be
made: 1) what information should be exchanged (that is, what of one
side's routing table should be propagated to the other side), and 2)
what routing algorithm should be used to exchange the information?
The first decision is discussed in section 10.1 below (Routing
Information Filtering). The latter decision is discussed here.
Conceptually, and to a large extent in practice, the routing
algorithms at each level are cleanly partitioned. This partition is
much like the partition between "egp" and "igp" level routing in IP,
but with Pip it exists at each level of the hierarchy.
At the top-level of the Pip Address hierarchy, a path-vector routing
algorithm is used. Path-vector is more appropriate at the top level
than link-state because path-vector does not require agreement
between top-level entities (providers) on metrics in order to be
loop-free. (Agreement between the providers is likely to result in
better paths, but the Pip Architecture does not assume such
agreement.)
The top-level path-vector routing algorithm is based on IDRP, but
enhanced to handle Pip addresses and Pip idiosyncrasies such as the
Routing Context. At any level below the top level, it is a local
decision as to what routing algorithm technology to run. However,
the path-vector routing algorithm is generalized so that it can run
at multiple levels of the Pip Address hierarchy. Thus, a lower level
domain can choose to take advantage of the path-vector algorithm, or
run another, such as a link-state algorithm. The modified version of
IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced
"milpiv").
Normally, information is exchanged between two separate routing
algorithms by virtue of the two algorithms co-existing in the same
router. For instance, a border router is likely to participate in an
exchange of routing information with provider routers, and still run
the routing algorithm of the internal routers. If the two algorithms
are different routing technologies (for instance, link-state versus
distance-vector) then internal conversion translates information from
one routing algorithm to the form of the other.
In some cases, however, two routing algorithms that exchange
information will exist in different routers, and will have to
exchange information over a link. If these two algorithms are
different technologies, then they need a common means of exchanging
routing information. While strictly speaking this is a local matter,
MLPV can also serve as the interface between two disparate routing
algorithms. Thus, all routers should be able to run MLPV, if for no
other reason than to exchange information with other, perhaps
proprietary, routing protocols.
MLPV is designed to be extendible with regards to the type of routes
that it calculates. It uses the Pip Object parameter identification
number space to identify what type of route is being advertised and
calculated [9]. Thus, to add new types of routes (for instance, new
types of service), it is only necessary to configure the routers to
accept the new route type, define metrics for that type, and criteria
for preferring one route of that type over another.
10.1 Routing Information Filtering
Of course, the main point behind having hierarchical routing is so
that information from one part of the hierarchy can be reduced when
passed to another. In general, reduction (in the form of
aggregation) takes place when passing information from the bottom of
the hierarchy up. However, Pip uses tunneling and exit routing to,
if desired, allow information from the top to be reduced when it goes
down.
When two routers become neighbors, they can determine what
hierarchical levels they have in common by comparing Pip Addresses.
For instance, if two neighbor routers have Pip Addresses 1.2.3,4 and
1.2.8,9.14 respectively, then they share levels 0 and 1, and are
different at levels below that. (0 is the highest level, 1 is the
next highest, and so on.) As a general rule, these two routers
exchange level 0, level 1, and level 2 routing information, but not
level 3 or lower routing information. In other words, both routers
know how to route to all things at the top level (level 0), how to
route to all level 1 things with "1" as the level 0 prefix, and how
to route to all level 2 things with "1.2" as the level 1 prefix.
In the absence of other instructions, two routers will by default
exchange information about all levels from the top down to the first
level at which they have differing Pip Addresses. In practice,
however, this default exchange is as likely to be followed as not.
For instance, assume that 1.2.3,4 is a provider router, and
1.2.8,9.14 is a subscriber router. (Note that 1.2.8 is the prefix
given the subscriber by the provider, thus the metalevel boundary
indicated by the comma.) Assume also that the subscriber network is
using destination-oriented transit-driven exit routing (see section
8.1). Finally, assume that router 1.2.8,9.14 is the subscriber's
only entry point into provider 1 (other routers provide entry points
to other providers).
In this case, 1.2.8,9.14 does not need to know about level 2 or level
1 areas in the provider (that is, it does not need to know about
1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on). Thus, 1.2.8,9.14
should be configured to inform 1.2.3,4 that it does not need level 1
or 2 information.
As another example, assume still that 1.2.3,4 is a provider and
1.2.8,9.14 is a subscriber. However, assume now that the subscriber
network is using host-driven exit routing. In this case, the
subscriber does not even need to know about level 0 information,
because all exit routing is directed to the provider of choice, and
having level 0 information therefore does not influence that choice.
11. Transition
The transition scheme for Pip has two major components, 1)
translation, and 2) encapsulation. Translation is required to map
the Pip Address into the IP address and vice versa. Encapsulation is
used for one Pip router (or host) to exchange packets with another
Pip router (or host) by tunneling through intermediate IP routers.
The Pip transition scheme is basically a set of techniques that
allows existing IP "stuff" and Pip to coexist, but within the
limitations of IP address depletion (though not within the
limitations of IP scaling problems). By this I mean that an IP-only
host can only exchange packets with other hosts in a domain where IP
numbers are unique. Initially this domain includes all IP hosts, but
eventually will include only hosts within a private domain. The IP
"stuff" that can exist includes 1) whole IP domains, 2) individual IP
hosts, 3) IP-oriented TCPs, and 4) IP-oriented applications.
11.1 Justification for Pip Transition Scheme
Note that all transition to a bigger address require translation. It
cannot be avoided. The major choices one must make when deciding on
a translation scheme are:
1. Will we require a contiguous infrastructure consisting of the new
protocol, or will we allow tunneling through whatever remains of
the existing IP infrastructure at any point in time?
2. Will we allow global connectivity between IP machines after IP
addresses are no longer globally unique, or not? (In other words,
will we use a NAT scheme or not? [15])
Concerning question number 1; while it is desirable to move as
quickly as possible to a contiguous Pip (or SIP or whatever)
infrastructure, especially for purposes of improved scaling, it is
fantasy to think that the whole infrastructure will cut over to Pip
quickly. Furthermore, during the testing stages of Pip, it is highly
desirable to be able to install Pip in any box anywhere, and by
tunneling through IP, create a virtual Pip internet. Thus, it seems
that the only reasonable answer to question number 1 is to allow
tunneling.
Concerning question number 2; it is highly desirable to avoid using a
NAT scheme. A NAT (Network Address Translation) scheme is one
whereby any two IP hosts can communicate, even though IP addresses
are not globally unique. This is done by dynamically mapping non-
unique IP addresses into unique ones in order to cross the
infrastructure. NAT schemes have the problems of increased
complexity to maintain the mappings, and of translating IP addresses
that reside within application data structures (such as the PORT
command in FTP).
This having been said, it is conceivable that the new protocol will
not be far enough along when IP addresses are no longer unique, and
therefore a NAT scheme becomes necessary. It is possible to employ a
NAT scheme at any time in the future without making it part of the
intended transition scheme now. Thus, we can plan for a NATless
transition now without preventing the potential use of NAT if it
becomes necessary.
11.2 Architecture for Pip Transition Scheme
The architecture for Pip Transition is that of a Pip infrastructure
surrounded by IP-only "systems". The IP-only "systems" surrounding
Pip can be whole IP domains, individual IP hosts, an old TCP in an
otherwise Pip host, or an old application running on top of a Pip-
smart TCP.
The Pip infrastructure will initially get its internal connectivity
by tunneling through IP. Thus, any Pip box can be installed
anywhere, and become part of the Pip infrastructure by configuration
over a "virtual" IP. Of course, it is desirable that Pip boxes be
directly connected to other Pip boxes, but very early on this is the
exception rather than the rule.
Two neighbor Pip systems tunneling through IP simply view IP as a
"link layer" protocol, and encapsulate Pip over IP just as they would
encapsulate Pip over any other link layer protocol. In particular,
the hop-count field of Pip is not copied into the Time-to-Live field
of IP. There is no automatic configuration of neighbor Pip systems
over IP. Manual configuration (and careful "virtual topology"
engineering) is required. Note that ICMP messages from a IP router
in a tunnel is not translated into a PCMP message and sent on. ICMP
messages are sinked at the translating router at the head of the
tunnel. The information learned from such ICMP messages, however,
may be used to determine unreachability of the other end of the
tunnel, and may there result in PCMP message on later packets.
In the remainder of this section, we do not distinguish between a
virtual Pip infrastructure on IP, and a pure Pip infrastructure.
Given the model of a Pip infrastructure surrounded by IP, there are 5
possible packet paths:
1. IP - IP
2. IP - Pip - IP
3. IP - Pip
4. Pip - IP
5. Pip - Pip
The first three paths involve packets that originate at IP-only
hosts. In order for an IP host to talk to any other host (IP or
not), the other host must be addressable within the context of the IP
host's 32-bit IP address. Initially, this "IP-unique" domain will
include all IP hosts. When IP addresses become no longer unique, the
IP-unique domain will include a subset of all hosts. At a minimum,
this subset will include those hosts in the IP-host's private domain.
However, it makes sense also to arrange for the set of all "public"
hosts, basically anonymous ftp servers and mail gateways, to be in
this subset. In other words, a portion of IP address space should be
set aside to remain globally unique, even though other parts of the
address space are being reused.
11.3 Translation between Pip and IP packets
Paths 2 and 4 involve translation from Pip to IP. This translation
is straightforward, as all the information needed to create the IP
addresses is in the Pip header. In particular, Pip IDs have an
encoding that allows them to contain an IP address (again, one that
is unique within an IP-unique domain). Whenever a packet path
involves an IP host on either end, both hosts must have IP addresses.
Thus, translating from Pip to IP is just a matter of extracting the
IP addresses from the Pip IDs and forming an IP header.
Translating from an IP header to a Pip header is more difficult,
because the 32-bit IP address must be "translated" into a 64-bit Pip
ID and a Pip Address. There is no algorithm for making this
translation. A table mapping IP addresses (or, rather, network
numbers) to Pip IDs and Pip Addresses is required. Since such a
table must potentially map every IP address, we choose to use dynamic
discovery and caching to maintain the table. We choose also to use
DNS as the means of discovering the mappings.
Thus, DNS contains records that map IP address to Pip ID and Pip
Address. In the case where the host represented by the DNS record is
a Pip host (packet path 3), the Pip ID and Pip Address are those of
the host. In the case where the host represented by the DNS record
is an IP-only host (packet paths 2 and 4), the Pip Address is that of
the Pip/IP translating gateway that is used to reach the IP host.
Thus, an IP-only domain must at least be able to return Pip
information in its DNS records (or, the parent DNS domain must be
able to do it on behalf of the child).
With paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating
gateway (IP to Pip) makes the DNS query. It stores the IP packet
while waiting for the answer. The query is an inverse address (in-
addr) using the destination IP address. The translating gateway can
cache the record for an arbitrarily long period, because if the
mapping ever becomes invalid, a PCMP Invalid Address message flushes
the cache entry.
In the case of path 4 (Pip-IP), however, the Pip Address of the
translating gateway is returned directly to the source host--
piggybacked on the DNS record that is normally returned. Thus this
scheme incurs only a small incremental cost over the normal DNS
query.
11.4 Translating between PCMP and ICMP
The only ICMP/PCMP messages that are translated are the Destination
Unreachable, Echo, and PTMU Exceeded messages. The portion of the
offending IP/Pip header that is attached to the ICMP/PCMP message is
not translated.
11.5 Translating between IP and Pip Routing Information
It is not necessary to pass IP routing information into the Pip
infrastructure. The mapping of IP address to Pip Address in DNS
allows Pip to find the appropriate gateway to IP in the context of
Pip addresses only.
It is impossible to pass Pip routing information into IP routers,
since IP routers cannot understand Pip addresses. IP domains must
therefore use default routing to reach IP/Pip translators.
11.6 Old TCP and Application Binaries in Pip Hosts
A Pip host can be expected to have an old TCP above it for a long
time to come, and a new (Pip-smart) TCP can be expected to have old
application binaries running over it for a long time to come. Thus,
we must have some way of insuring that the TCP checksum is correctly
calculated in the event that one or both ends is running Pip, and one
or both ends has an old TCP binary. In addition, we must arrange to
allow applications to interface with TCP using a 32-bit "address"
only, even though those 32 bits get locally translated into Pip
Addresses and IDs.
As stated above, in all cases where a Pip host is talking to an IP-
only host, the Pip host has a 32-bit IP address. This address is
embedded in the Pip ID such that it can be identified as an IP
address from inspection of the Pip ID alone.
The TCP pseudo-header is calculated using the Payload Length and
Protocol fields, and some or all of the Source and Dest Pip IDs. In
the case where both Source and Dest Pip IDs are IP-based, only the
32-bit IP address is included in the pseudo-header checksum
calculation. Otherwise, the full 64 bits are used. (Note that using
the full Payload Length and Protocol fields does not fail when old
TCP binaries are being used, because the values for those fields must
be within the 16-bit and 8-bit limits for TCP to correctly operate.)
The reason for only using 32 bits of the Pip ID in the case of both
ends using an IP address is that an old TCP will use only 32 bits of
some number to form the pseudo-header. If the entire 64 bits of the
Pip ID were used, then there would be cases where no 32-bit number
could be used to insure that the correct checksum is calculated in
all cases.
Note that in the case of an old TCP on top of Pip, "Pip" (actually, a
Pip daemon) must create a 32-bit number that can both be used to 1)
allow the Pip layer to correctly associate a packet from the TCP
layer with the right Pip header, and 2) cause the TCP layer to
calculate the right checksum. (This number is created when the
application initiates a DNS query. A Pip daemon intervenes in this
request, calculates a 32 bit number that the application/TCP can use,
and informs the Pip layer of the mapping between this 32 bit number
and the full Pip header.)
When the destination host is an IP only host, then this 32-bit number
is nothing more than the IP address. When the destination host is a
Pip host, then this 32-bit number is some number generated by Pip to
"fool" the old TCP into generating the right checksum. This 32-bit
number can normally be the same as the lower 32 bits of the Pip ID.
However, it is possible that two or more active TCP connections is
established to different hosts whose Pip IDs have the same lower 32
bits. In this case, the Pip layer must generate a different 32-bit
number for each connection, but in such a way that the sum of the two
16-bit components of the 32-bit numbers are the same as the sum of
the two 16-bit components of the lower 32 bits of the Pip IDs.
In the case where an old Application wants to open a socket using an
IP address handed to it (by the user or hard-coded), and not using a
domain name, then it must be assumed that this IP address is valid
within the IP-unique domain. To form a Pip ID out of this 32-bit
number, the host appends the high-order 24 bits of its own Pip ID,
plus the IP-address-identifier-byte value, to the 32-bit IP address.
11.7 Translating between Pip Capable and non-Pip Capable DNS Servers
In addition to transitioning "Pip-layer" packets, it is necessary to
transition DNS from non-Pip capable to Pip capable. During
transition there will be name servers in DNS that only understand IP
queries and those that understand both Pip and IP queries. This
means there must be a mechanism for Pip resolvers to detect whether a
name server is Pip capable, and vice versa. Also, a name server, if
it provides recursive service, must be able to translate Pip requests
to IP requests. (Pip-capable means a name server understands Pip and
existing IP queries. It does not necessarily mean the name server
uses the Pip protocol to communicate.)
New resource records have been defined to hold Pip identifiers and
addresses, and other information [1]. These resource records must be
queried using a new opcode in the DNS query packet header. Existing
resource records can be queried using both the old and new header
formats. Name servers that are not Pip-capable will respond with a
format error to queries with the new opcode. Thus, a resolver can
determine dynamically whether a name server is Pip-capable, by
sending it a Pip query and noting the response. This only need be
done once, when querying a server for the "first" time, and the
outcome can be cached along with the name server's address.
Using a new opcode for making Pip queries also helps name servers
determine whether a resolver is Pip-capable (it is not always not
obvious from the type of query made since many queries are common to
to IP and Pip). Determining whether a resolver is Pip-capable is
necessary when responding with address information that is not
explicitly requested by the query. An important example of this is
when a name server makes a referral to another name server in a
response: if the request comes from a Pip resolver, name server
addresses will be returned as Pip identifier/address resource
records, otherwise the addresses will be returned as IP A resource
records.
Those servers that are Pip-capable and provide recursive service must
translate Pip requests to IP requests when querying an IP name
server. For most queries, this will just mean modifying the opcode
value in the query header to reflect an IP query, rather than a Pip
query. (Most queries are identical in IP and Pip.) Other queries,
notably the query for Pip identifier/address information, must be
translated into its IP counterpart, namely, an IP A query. On
receipt of an answer from an IP name server, a Pip name server must
translate the query header and question section back to its original,
and format the answer appropriately. Again, for most queries, this
will be a trivial operation, but responses containing IP addresses,
either as a result of an explicit query or as additional information,
must be formatted to appear as a valid Pip response.
Pip-capable name servers that provide recursive name service should
also translate IP address requests into Pip identifier/address
requests when querying a Pip-capable name server. (A host's IP
address can be deduced from the host's Pip identifier.) This enables
a Pip-capable name server to cache all relevant addressing
information about a Pip host in the first address query concerning
the host. Caching partial information is undesirable since the name
server, using the current DNS caching strategy, would return only the
cached information on a future Pip request, and IP, rather than Pip,
would be used to communicate with the destination host.
12. Pip Address and ID Auto-configuration
One goal of Pip is to make networks as easy to administer as
possible, especially with regards to hosts. Certain aspects of the
Pip architecture make administration easier. For instance, the ID
field provides a network layer "anchor" around which address changes
can be administered.
This section discusses three aspects of autoconfiguration; 1)
domain-wide Pip Address prefix assignment, 2) host Pip Address
assignment, and 3) host Pip ID assignment.
12.1 Pip Address Prefix Administration
A central premise behind the use of provider-rooted hierarchical
addresses is that domain-wide address prefix assignment and re-
assignment is straight-forward. This section describes that process.
Pip Address prefix administration limits required manual prefix
configuration to DNS and border routers. This is the minimum
required manual configuration possible, because both border routers
and DNS must be configured with prefix information for other reasons.
DNS must be configured with prefix information so that it can reply
to address queries. DNS files are structured so that the prefix is
administered in only one place (that is, every host record does not
have to be changed to create a new prefix). Border routers must be
configured with prefix information in order to advertise exit routes
internally.
Note in particular that no internal (non-border) routers or hosts
need ever be manually configured with any externally derived
addressing information. All internal routers that are expected to
fall under a common provider-prefix must, however, be configured with
a "group ID" taken from the Pip ID space. (This group ID is not a
multicast ID per se. Rather, it is an identifier that allows prefix
updates to be targetted to a specific set of routers.)
Each border router is configured with the following information.
1. The type of exit routing for the domain. This tells the border
router whether or not it needs to advertise external routes
internally.
2. The address prefix of the providers that the border is directly
connected to. This prefix information includes any metalevel
boundaries above the subscriber/provider metalevel boundary
(called simply the subscriber metalevel).
3. Other information about the provider (provider name, type, user
access restriction classes).
4. A list of common-provider-prefix group IDs that should receive the
auto-configuration information. (The default is that only systems
that share a group ID with the border router will receive the
information.)
This information is injected into the intra-domain routing algorithm.
It is automatically spread to all routers indicated by the group ID
list. This way, the default behavior is for the information to be
automatically constrained to the border router's "area".
When a non-border router receives this information, it 1) records the
route to the providers in its forwarding table, and 2) advertises the
information to hosts in the router discovery protocol [8]. Thus
hosts learn not only their complete address, but also information on
how to do exit routing and on how to choose source addresses.
12.2 Host Autoconfiguration
There are three phases of host autoconfiguration:
1. The host locally creates a flat unique Pip ID (probably globally
unique but at least unique on the attached subnet).
2. The host learns its Pip Addresses.
3. The host optionally obtains a hierarchical, organizationally
meaningful Pip ID and a domain name from a Pip ID/domain name
assignment service. This service updates DNS.
Item three is optional. If Pip ID and domain name assignment
services are not installed, then the host must obtain its domain name
and, if necessary, Pip ID, from static configuration. Each of the
three phases are described below.
12.2.1 Host Initial Pip ID Creation
When a host boots, it can form an ID based only on local information.
If the host has an IEEE 802 number, either from an IEEE 802 interface
or from an internal identifier, then it can create a globally unique
Pip ID from the IEEE 802 Pip ID type [4]. Otherwise, the host can
create an ID from the IEEE 802 space using its subnet (link layer)
address. This latter ID is only guaranteed to be locally unique.
12.2.2 Host Pip Address Assignment
Unless a host does not wish to use ID-tailed Pip Addresses (see
section 4.1.2), host Pip Address assignment is trivial. (The near-
term Pip Architecture doesn't specify a means for a host to obtain a
non-ID-tailed Pip Address.) When a host attaches to a subnet, it
learns the Pip Address of the attached routers through router
discovery.
The host simply adopts these Pip Addresses as its own. The Pip
Address gets a packet to the host's subnet, and the host's Pip ID is
used to route across the subnet. When the routers advertise new
addresses (for instance, because of a new provider), the host adopts
the new addresses.
12.2.3 Pip ID and Domain Name Assignment
Once the host has obtained its Pip Addresses and an at-least-
locally-unique Pip ID, it can exchange packets with an ID/Domain Name
(ID/DN) assignment service. If the host locally created a globally
unique Pip ID (using an IEEE 802 number), and the organization it
belongs to does not use organizationally structured Pip IDs (which
should normally be the case) then it only needs to obtain a domain
name. The ID/DN assignment service is reachable at a well-known
anycast address [4]. Thus, the host is able to start exchanging
packets with the ID/DN assignment service without any additional
configuration.
If there is no ID/DN assignment service available, then the host must
obtain it's organizational ID or DNS name in a non-automatic way. If
the ID/DN assignment service is down, the host must temporarily
suffice with just a Pip ID and Address. The host can periodically
try to reach the ID/DN assignment service.
The ID/DN assignment service must coordinate with DNS. When the
ID/DN assignment service creates a new ID or domain name to assign to
a new host, it must know which IDs and domain names are available for
assignment. It must also update DNS with the new information.
The design of this service is left for further study.
13. Pip Control Message Protocol (PCMP)
The Pip analog to ICMP is PCMP [7]. The near-term Pip architecture
defines the following PCMP messages:
1. Local Redirect
2. Packet Not Delivered
3. Echo
4. Parameter Problem
5. Router Discovery
6. PMTU Exceeded
7. Provider Redirect
8. Reformat Transit Part
9. Unknown Parameter
10. Host Mobility
11. Exit PDN Address
The Local Redirect, Echo, and Parameter Problem PCMP messages operate
almost identically to their ICMP counterparts.
The Packet Not Delivered PCMP message serves the role of ICMP's
Destination Unreachable. The Packet Not Delivered, has two major
differences. First, it is more general in that it indicates the
hierarchy level of unreachability (rather than explicit host, subnet,
network unreachability as with IP). Second, it indicates when an
address is known to be invalid, thus allowing for more intelligent
use of DNS (see section 6.2).
The Router Discovery PCMP message operates as ICMP's, with the
exception that a host derives its Pip Address from it.
The PMTU Exceeded message operates as ICMP's, with the exception that
the Pip header size of the offending Packet is also given. This
allows the source host transport to determine how much smaller the
packet PMTU should be from the advertised subnet PMTU. Note that if
an occasional option, such as the PDN Address option, needs to be
attached to one of many packets, and that this option makes the
packet larger than the PMTU, then it is not necessary to modify the
MTU coming from transport. Instead, that packet can be fragmented by
the host's Pip forwarding engine. (Pip specifies
fragmentation/reassembly for hosts but not for routers. The
fragmentation information is in a Pip Option.)
The Provider Redirect, Invalid Address, Reformat Transit Part,
Unknown Parameter, Host Mobility, and Exit PDN Address PCMP messages
are new.
The Provider Redirect PCMP message is used to inform the source host
of a preferable exit provider to use when provider-rooted, transit-
driven exit routing is used (see section 8.1).
The Invalid Address PCMP message is used to inform the source host
that none of the IDs of the destination host match that of the Pip
packet. The purpose of this message is to allow for authoritative
DNS requests (see section 6.2).
The Reformat Transit Part PCMP message has both near-term Pip
architecture functions and evolution functions. Near-term, the
Reformat Transit Part PCMP message is used to indicate to the source
whether it has too few or too many layers of address in the Routing
Directive (see section 8.2). Long-term, the Reformat Transit Part
PCMP message is able to arbitrarily modify the transit part
transmitted by the host, as encoded by a bit string.
The Unknown Parameter PCMP message is used to inform the source host
that the router does not understand a parameter in either the
Handling Directive, the Routing Context, or the Transit Options. The
purpose of this message is to assist evolution (see section 16.1).
The Host Mobility PCMP message is sent by a host to inform another
host (for instance, the host's Mobile Address Server) that it has a
new address (see section 14). The main use of this packet is for
host mobility, though it can be used to manage any address changes,
such as because of a new prefix assignment.
The Exit PDN Address PCMP message is used to manage the function
whereby the source host informs the PDN entry router of the PDN
Address of the exit PDN system (see section 15).
When a router needs to send a PCMP message, it sends it to the source
Pip Address. If the Pip header is in a tunnel, then the PCMP message
is sent to the router that is the source of the tunnel. Depending on
the situation, this may result in another PCMP message from the
source of the tunnel to the true source (for instance, if the source
of the tunnel finds that the dest of the tunnel can't be reached, it
may send a Packet Not Delivered to the source host).
14. Host Mobility
Depending on how security conscience a host is, and what security
mechanisms a host has available, mobility can come from Pip "for
free". If a host is willing to accept a packet by just looking at
source and destination Pip ID, and if the host simply records the
source Pip Address on any packet it receives as the appropriate
return address to the source Pip ID, then mobility comes
automatically.
That is, when a mobile host gets a new Pip Address, it simply puts
that address into the next packet it sends. When the other host
receives it, it records the new Pip Address, and starts sending
return packets to that address. The security aspect of this is that
this type of operation leads to an easy way to spoof the (internet
level) identity of a host. That is, absent any other security
mechanisms, any host can write any Pip ID into a packet. (Cross-
checking a source Pip ID against the source Pip Address at least
makes spoofing of this sort as hard as with IP. This is discussed
below.)
The above simple host mobility mechanism does not work in the case
where source and destination hosts obtain new Pip Addresses at the
same time and the old Pip addresses no longer work, because neither
is able to send its new address information directly to the other.
Furthermore, if a host wishes to be more secure about authenticating
the source Pip ID of a packet, then the above mechanism also is not
satisfactory. In what follows, the complete host mobility mechanism
is described.
Pip uses the Mobile Host Server and the PCMP Host Mobility message to
manage host mobility;
The Mobile Host Server is a non-mobile host (or router acting as a
host) that keeps track of the active address of a mobile host. The
Pip ID and Address of the Mobile Host Server is configured into the
mobile host, and in DNS. When a host X obtains information from DNS
about a host Y, the Pip ID and Address of host Y's Mobile Host Server
is among the information. (Also among the information is host Y's
"permanent" address, if host Y has one. If host Y is so mobile that
it doesn't have a permanent address, then no permanent address is
returned by DNS. In particular, note that DNS is not intended to
keep track of a mobile host's active address.)
Given the destination host's (Y) permanent ID and Address, and the
Mobile Host Server's permanent IDs and Addresses, the source host (X)
proceedes as follows. X tries to establish communications with Y
using one of the permanent addresses. If this fails (or if at any
time X cannot contact Y), X sends a PCMP Mobile Host message to the
Mobile Host Server requesting the active address for Y. (Note that X
can determine that it cannot contact Y from receipt of a PCMP
Destination Unreachable or a PCMP Invalid Address message.)
The Mobile Host Server responds to X with the active Pip Addresses of
Y. (Of course, Y must inform its Mobile Host Server(s) of its active
Pip Addresses when it knows them. This also is done using the PCMP
Mobile Host message. Y also informs any hosts that it is actively
communicating with, using either a regular Pip packet or with a PCMP
Mobile Host message. Thus, usually X does not need to contact the
Mobile Host Server to track Y's active address.)
If the address that X already tried is among those returned by Y,
then the source host has the option of either 1) continuing to try
the same Pip Address, 2) trying another of Y's Pip Addresses, 3)
waiting and querying the Mobile Host Server again, or 4) giving up.