Transit Network Selection draft

[Robert L Ullmann <[e-mail]>]

TP/IX Working Group                                        R. L. Ullmann
Internet Draft                              Process Software Corporation
                                                           June 14, 1993






                   Transit Policy Routing in TP/IX

1  Status of this Memo

This memo discusses the requirements of transit policy routing, and
methods of implementation using TP/IX-IPv7 and RAP.  It is
informational.

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups.  (Note that other groups may also distribute
working documents as Internet Drafts).

Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."

Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.































Ullmann            DRAFT: expires December 13, 1993            [page  1]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


2  Contents

        1       Status of this Memo  . . . . . . . . . . . . . . . . 1
        2       Contents . . . . . . . . . . . . . . . . . . . . . . 2
        3       Introduction . . . . . . . . . . . . . . . . . . . . 3
        4       Outline of requirements  . . . . . . . . . . . . . . 3
        4.1       Source selection . . . . . . . . . . . . . . . . . 4
        4.2       USA legal requirement  . . . . . . . . . . . . . . 4
        5       Basic service offering scenario  . . . . . . . . . . 5
        5.1       Routes offered by IXCs . . . . . . . . . . . . . . 5
        5.2       Cost-based selection . . . . . . . . . . . . . . . 5
        5.3       Per-datagram route identification  . . . . . . . . 6
        6       Transit Network Identifier . . . . . . . . . . . . . 6
        7       References . . . . . . . . . . . . . . . . . . . . . 7
        8       Author's Address . . . . . . . . . . . . . . . . . . 7












































Ullmann            DRAFT: expires December 13, 1993            [page  2]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


3  Introduction

The future Internet must support routing under a number of policy
constraints, some of which will appear very arbitrary from a technical
standpoint, being based on political regulations and such mundane
issues as minimizing the monentary cost of specific traffic flows.

One specific requirement is the ability of a traffic source to select
the transit network(s) to be used for specific subsets of the offerred
traffic.

While this memo discusses the use of RAP as the routing protocol to
provide the policy selection required, this is not exclusive:  any
routing protocol with the proper features may be used over TP/IX-IPv7
to meet the requirements.

Note that while the problems and methods describe the relationship
between commercial local-exchange and inter-exchange carriers and
their customers, the discussion applies equally well to the cost
management problems that occur within large organizations and within
the network service providers themselves.

4  Outline of requirements

The considerations for selection of IXCs (inter-exchange carriers, in
terminology derived from USA usage) include cost, availability, local
policies (such as contracts with IXCs), non-local policies (national
rules on transit traffic), and the human desire to control what is
controllable:  e.g., management says we are to use carrier X for all
EDI traffic.

These considerations can vary rapidly, and multiple selection
decisions may be in use simultaneously.  A particular source may at
the same time be routing some traffic via one carrier, and some via
another; there may be dozens of carriers involved.

Cost can vary in real time, and may also be affected by volume
discount programs (known to the customer and the IXC, but not known to
the local exchange).  In particular, IXCs may offer pricing in real
time, in response to network load or any other factor the IXC wants to
take into account.

Availability is subject to change:  a major failure within one IXC
will result in traffic being transferred to others.  It is best if
this is done by the customer selecting routes, not by "splashing." At
the same time, this is going to trip overload event triggers in other
IXCs as traffic is transferred, and the results of those trips
(premium pricing, rate limitations) must be communicated to the users.

A good description of some related problems can be found in [Perl92]
pages 245 ff.








Ullmann            DRAFT: expires December 13, 1993            [page  3]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


4.1  Source selection

In the following diagram A and B are traffic sources within a customer
network, C is the "border" router within the customer's management, N
is the first router within the local exchange.

D-F is one transit network, and E-G is another.  The destination of
the traffic is X (possibly with its own set of local exchange and
internal routers.) Each router may, of course, be a number of routers
in some locally defined topology; they are abstracted here as one.



                A                D ------ ... ------ F
                 \              /                     \ 
                  \            /                       \
                   \          /                         \
                    C ------ N                           X
                   /          \                         /
                  /            \                       /
                 /              \                     /
                B                E ------ ... ------ G




Router C must be able to acquire knowledge in real time of the
availability and costs of the transit networks, and be able to select
one for each datagram forwarded to router N.  C must also be able to
offer this same degree of flexibility in network selection to A and B.

Likewise, router N must be able to determine which transit network to
use for each datagram received from C, and be able to offer the routes
to C.

All of the decisions that may possibly be affected by policy must be
made available to the customer's equipment.

4.2  USA legal requirement

In particular, it is not only unacceptable, but actually illegal in
the USA for a local provider to make a decision selecting an
inter-exchange provider on behalf of the customer.  The present
providers of the Internet service in the USA avoid this by using lines
leased from the local provider (regional Bell operating company (RBOC)
or other local exchange company (LEC)); this effectively excludes the
RBOCs and other LECs from the business of providing Internet service
under the present (IPv4) routing paradigm.

To meet the equal access requirements, the LECs must provide the
ability to pre-subscribe a line (not difficult, even with IPv4,
although it may cause troublesome interactions with IPv4 routing
protocols).  The LECs must also provide "per-call" transit network
selection.  In a connectionless network layer service, this means
per-datagram selection.




Ullmann            DRAFT: expires December 13, 1993            [page  4]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


While this requirement is specific to the USA, other countries can be
expected to establish similar requirements as they open their telecoms
markets to direct competition.

5  Basic service offering scenario

Given the complexity of the requirements, it is clear that no
standardized structure for making decisions within the (provider)
network on the basis of requests for grades of service is going to be
adequate.  Individual "calls", i.e.  flow setups, can demand specific
resources, but the general decision making must be offered to the
customer equipment, where a decision of arbitrary complexity on an
arbitrary set of constraints can be made.

The method used in IPv7 and RAP to provide this level of service is
described in the following sections.

5.1  Routes offered by IXCs

Each IXC offers a set of routes via its interconnection points with
the LECs.  Each route describes a particular aggregation of
destinations; by country, AD, whatever hierarchy may be established
with an AD, or individual networks.  In some cases, it may be for
individual "hosts"; addresses of well-known service offerings, along
the lines of (the USA) "800" numbers, which can be located anywhere,
via any provider.

There may also be routes offered for individual hosts that are roaming
in the cellular/wireless service; this may ordinarily be via different
interconnection points, and then aggregated into the general service.

Each route carries a tag identifying the transit provider.  It also
carries descriptors of cost and other attributes of the path(s)
offered.  Some of the routes may carry the target attribute:  i.e.,
the LEC is directed to offer the route only to one specific customer
or aggregation.

The LECs then offer these routes to their customers, subject to any
local policies of the LEC or pre-subscription of the customer.  The
offered routes carry forward route identifiers assigned by the LEC
router.

5.2  Cost-based selection

The router at or near the traffic source can then make a decision to
use one or more particular routes for a destination.  This decision
may be based on cost, as viewed by the policies of its owner.

A pure monentary-cost based decision may result in very frequent
changes of transit network selection, as the networks compete in real
time for traffic.  Some attention may need to be given to maintaining
network stability in this case.







Ullmann            DRAFT: expires December 13, 1993            [page  5]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


5.3  Per-datagram route identification

The router making a decision then identifies the route desired by
copying the forward route identifier from RAP into the FrID field in
the datagrams.

For flow, or full connection-based circuit setup, the source router
uses the FrID in the setup exchange, and then records the flow ID or
circuit LCN (logical channel number) in the FrID field of the IPv7
datagram.  If RAP is being used as the setup protocol, this reduces to
the same operation.

6  Transit Network Identifier

The Transit Network Identifier option of RAP (type 14, format 2, class
any) tags a route as being offered by a particular transit network.
This permits datagram source selection of route(s) traversing or not
traversing the identified network.

The data is a domain name, probably the name of the network, although
it may be the name of the organization owning the network,
particularily in the case of a commerical service offering.  It may
also be a domain name assigned specifically for this purpose within
the naming domain of an organization.



































Ullmann            DRAFT: expires December 13, 1993            [page  6]

Internet draft       Transit Policy Routing in TP/IX       June 14, 1993


7  References

 [Perl92]    Radia Perlman.  Interconnections:  Bridges and Routers.
               Addison-Wesley.  Reading, Massachusetts.  1992.

 [ID-TPIX]   Robert Ullmann.  TP/IX:  The Next Internet.  Internet
               draft:  unpublished at this writing.  March, 1993.

 [ID-RAP]    Robert Ullmann.  RAP:  Internet Route Access Protocol.
               Internet draft:  unpublished at this writing.  January,
               1993.

8  Author's Address


Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA

Phone: [phone] x226
Email: [e-mail]





































Ullmann            DRAFT: expires December 13, 1993            [page  7]