----------------------------------------------------------------------
ICANN:
Ad Hoc Committee on Addressing
Ad Hoc Effort Bibliography
----------------------------------------------------------------------
February 2000,
version 1PURPOSE AND MOTIVATION
This document is intended to be a basic, annotated
bibliography for use
in ICANN's Ad Hoc effort. The bibliography points to
documents that
descirbe IPv4 and IPv6 addressing policies and protocols, documents
that
describe the intersection between the addressing requirements for
IP and other
technologies (especially PSTN and mobile), and general or
tutorial documents on
addressing policy. This bibliography is not
intended to be an exhaustive
reference to all available literature on
Internet addressing; instead it is intended
to be a basic contribution
to the ICANN Ad Hoc effort and its Terms of Reference.
For
each document in the bibliography the author, date and availability
of the document
is provided. This is the first version of the
document.
TABLE OF CONTENTS
The
document is divided into sections:
Section 1: IPv4 and IPv6 Addressing in
the Internet
Section 1, part 1: IPv4 Policies and Protocols
Section 1, part 2: IPv6 Policies and Protocols
Section 2: Impacts
on Addressing of New Technologies
Section 3: General and Tutorial documents
SUBSEQUENT
VERSIONS
The editor of this document expects that contributions and suggestions
by
the community will lead to further versions of this document.
Suggestions for
additions and corrections are cheerfully welcomed.
Contact information for the
editor is at the end of the document.
CONTACT INFORMATION
This document was compiled
by Mark McFadden, Commercial Internet
eXchange, Herndon, Virginia. Any errors
or ommissions are my
responsibility and corrections, suggestions, and proposals
for further
contributions are welcomed by the editor:
Mark McFadden
mcfadden@cix.org
PO
Box 7102
Madison, Wisconsin 53707-5707
US
----------------------------------------------------------------------
Section
1: IPv4 and IPv6 Addressing in the Internet
Part 1: IPv4 Policies and Protocols
----------------------------------------------------------------------
ISP
GUIDELINES FOR REQUESTING INITIAL IP ADDRESS SPACE
Author: ARIN
Date: Unknown
Available
at: http://www.arin.net/regserv/initial-isp.html
This is ARIN's document
that describes ISP guidelines for requesting
initial allocations of IP address
space. ARIN allocates IP address
prefixes no longer than /20. To recieve
an initial allocation an
organization must demonstrate the efficient utilization
of a minimum
contiguous or non-contiguous /21 (eight /24s) and provide reassignment
information
for /29 and shorter prefix lengths using the Shared WHOIS
Project (SWIP) or by
providing the same information fields in an RWHOIS
server. Organizations
requesting address space from ARIN must also
provide detailed information showing
that a /20 will be utilized within
three months and agree that the new /20 will
be used to renumber out of
the current addresses which will be returned to their
upstream
provider(s) within 18 months. The document provides additional
language
that defines how requests from calble-based providers are to
be handled.
ISPs that have residential cable subscribers use Net 24
address space to provide
cable service to their customers. In most
cases, these ISPs do not assign space
to individual customers, but
rather allocate it to the part of the cable infrastructure
to which
customers connect. ARIN also makes "micro-allocations" to exchange
points
in the Internet. Some public exchange points are considered to
be part of
the critical infrastructure of the Internet. ARIN makes
micro-allocations to these
public exchange points no longer than a /24.
EUROPEAN INTERNET REGISTRY POLICIES
AND PROCEDURES
Author: RIPE Local Internet Registry Working Group
Date: October
1998
Available at: http://www.ripe.net/ripe/docs/ripe-185.html
This is RIPE's
document that describes the procedures for requesting
allocations of IP address
space. RIPE follows the same procedures for
allocation decision regardless
of whether the allocation is an
additional allocation or an initial allocation.
The requestor is
required to provide information on the size of the request, the
structure
of the network and how the addresses are to be used, the
number of subnets and
type of IP connection or transit in place. The
requestor must also submit
an addressing plan that describes the
projected use of the space. Every
request in given an individual
evaluation process that takes current RIPE assignment
guidelines into
account. Local IRs are given an initial /19 from which to
allocate
addresses. Additional allocation requests can be made when the
currently
allocated address space is nearly used up (about 80 percent).
In addition, the
RIPE NCC recommends that local registries set up
reverse delegation services for
all of the addresses assigned for their
own infrastructure and to their customers.
The document gives an
explanation of the local regustry concept and the procedures
for
becoming a local registry in RIPE's area of responsibility.
POLICIES FOR
ADDRESS SPACE MANAGEMENT IN THE ASIA PACIFIC REGION
Author: APNIC
Date: January
2000
Available at: http://www.apnic.net
APNIC delegates address assignment authority
to local IRs and national
IRs who then apply APNIC's policies. All IR's
are to adopt consistent
address space management space policies and treat address
assignements
as "leases." The need for documentation, security and confidentiality
are
stressed in the assignment process. Like ARIN and RIPE, APNIC uses
a slow
start mechanism for initial allocations. While there are
exceptions to the
slow start process, the slow start mechanism is used
to ensure that large blocks
of address space are used, if they are
assigned. The maximum assignment
window for a LIR is a /19.
INTERNET REGISTRY IP ALLOCATION GUIDELINES
Authors:
Hubbard, Kosters, Conrad, Karrenberg, Postel
Date: November 1996
Available
at: ftp://ftp.isi.edu/in-notes/bcp/bcp12.txt
This document is the current IP address
assignment policy and
distribution document for unicast IPv4 addresses.
The document
describes not only the rules and guidelines for governing the
distribution
of the address space, but also the underlying registry
system. The document
has a section of the local assignment policies of
each registry, but these sections
have been rendered obsolete by
document specific to each registry. The document
does not address
multicast or private address space. This document is known
both as RFC
2050 and as BCP (Best Current Practices) 12.
ADMINISTRATIVELY SCOPED
IP MULTICAST ADDRESS SPACE
Author: Meyer
Date: July 1998
Available at: ftp://ftp.isi.edu/in-notes/bcp/bcp23.txt
This
document defines the "administratively scoped IPv4 multicast
space" to be the
range 239.0.0.0 to 239.255.255.255. In addition, it
describes a simple set of
semantics for the implementation of
Administratively Scoped IP Multicast. Administratively
Scoped Multicast
was a response to architectural problems identified in using
the TTL
field in the IP header for multicast scoping. The document uses
the
range to provide local scope addresses and organization local scope
addresses.
Finally, it provides a mapping between the IPv6 multicast
address classes documented
in RFC 1884 and IPv4 multicast address
classes. The document is RFC 2365 and BCP
23.
AN APPEAL TO THE INTERNET COMMUNITY TO RETURN UNUSED IP NETWORKS (AND
PREFIXES)
TO THE IANA
Author: Nesser
Date: February 1996
Available at: ftp://ftp.isi.edu/in-notes/bcp/bcp4.txt
This
document, written when there was little certainty about the pace
of exhaustion
of Ipv4 address space, was an appeal to the Internet
community at-large to return
unused address space. In some cases,
notably Stanford University, large
amounts of space was returned for
reallocation to the registries. The document
also requests that ISPs
return unused prefixes which fall outside their usual
address blocks to
the IANA for reuse. The document is RFC 1917 and BCP 4.
ADDRESS
ALLOCATION FOR PRIVATE INTERNETS
Authors: Rekhter, Moskowitz, Karrenberg, de Groot,
Lear
Date: February 1996
Available at: ftp://ftp.isi.edu/in-notes/bcp/bcp5.txt
This
document provides the rationale and standards for private IPv4
address space.
Specifically it carves out three CIDR blocks for use in
private networks:
10.0.0.0 - 10.255.255.255
(10/8 prefix)
172.16.0.0 -
172.31.255.255 (172.16/12 prefix)
192.168.0.0
- 192.168.255.255 (192.168/16 prefix)
The document discusses
the advantages and disadvantages of using
private address space. The document
is RFC 1918 and BCP 5.
IMPLICATIONS OF VARIOUS ADDRESS ALLOCATION POLICIES FOR
INTERNET
ROUTING
Authors: Rekhter, Li
Date: October 1996
Available
at: ftp://ftp.isi.edu/in-notes/bcp/bcp7.txt
This document examines the implications
of a variety of address
allocation policies and their effect on routing in the
public Internet.
The RFC addresses the intrinsic value of IPv4 addresses as well
as
providing a technical overview of hierarchical routing in the Internet.
The
implications of hierarchical routing on routing tables and address
policy are
examined in detail. The document examines the interaction
of address allocation
policy with the implications of that policy on
routing. As an example the
document says, "IP address allocation and
management policy is a complex, multifaceted
issue. It covers a broad
range of issues, such as who formulates the policies,
who executes the
policies, what is the role of various registries, what is the
role of
various organizations (e.g., ISOC, IAB, IESG, IETF, IEPG, various
government
bodies, etc.), the participation of end users in requesting
addresses, and so
on. Address allocation and management and the
scalability of the routing
system are interrelated - only certain
address allocation and management policies
yield scalable routing. The
Internet routing system is subject to both technological
and
fundamental constraints. These constraints restrict the choices of
address
allocation policies that are practical." Scalability of
routing is a key
topic and the document concludes by suggesting that
addresses should be "lent"
to those who use them rather than "owned" by
those that use them. The document
is RFC 2008 and BCP 7.
DOCUMENTING SPECIAL USE IPV4 ADDRESS BLOCKS
Author: Manning
Date:
June 1999
Available at:
http://www.ietf.org/internet-drafts/draft-manning-dsua-01.txt
This
document lists the existent special use prefixes from the IPv4
space that have
been registered with the IANA and provides some
suggestions for operational procedures
when these prefixes are
encountered. This document does not address IPv4
space that is
reserved for future delegation in the operational Internet.
The
current list of special use prefixes:
0.0.0.0/8
127.0.0.0/8
192.0.2.0/24
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
all D/E space (RFC 1166)
The document is currently an Internet
Draft and is a work in progress.
----------------------------------------------------------------------
Section
1: IPv4 and IPv6 Addressing in the Internet
Part 1: IPv6 Policies and Protocols
----------------------------------------------------------------------
IP
VERSION 6 ADDRESSING ARCHITECTURE
Authors: Hinden, Deering
Date: July 1998
Available
at: ftp://ftp.isi.edu/in-notes/rfc2373.txt
This specification defines the addressing
architecture of the IP
Version 6 protocol. IPv6 addresses are 128-bit identifiers
for
interfaces and groups of interfaces including unicast addresses,
anycast
addresses, and multicast addresses. The addresses are
specified as eight
16-bit pieces of the address. Two other notations
are provided for in the
specification. Several types of IPv6 addresses
are provided for: reserved
addresses (for NSAP and IPX allocation, as
well as addresses reserved in general),
aggregatable global unicast
addresses, link-local and site local unicast addresses,
and multicast
addresses. IPv6 unicast addresses are aggregatable with
contiguous
bit-wise masks similar to IPv4 addresses under Class-less Interdomain
Routing
(CIDR). The document is RFC 2373 and is in the IETF's
standards track.
AN
IPV6 AGGREGATABLE GLOBAL UNICAST ADDRESS FORMAT
Authors: Hinden, O'Dell, Deering
Date:
July 1998
Available at: ftp://ftp.isi.edu/in-notes/rfc2374.txt
This document
replaces the original IPv6 address format which was
previously defined in RFC
2073. The intent is to provide a new format
that provides greater aggregation
for more effective routing. The
other improvements over RFC 2073 included
removal of the registry bits
because they are not needed for route aggregation,
support of EUI-64
based interface identifiers, support of provider and exchange
based
aggregation, separation of public and site topology, and new
aggregation
based terminology.
The aggregatable global unicast address format is as follows:
| 3| 13 | 8 | 24 | 16 |
64 bits
|
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA |
Interface ID |
|
| ID | | ID | ID |
|
+--+-----+---+--------+--------+--------------------------------+
--Public Topology--- Site
--------
Topology
------Interface Identifier-----
Where
FP Format Prefix (001)
TLA ID Top-Level Aggregation Identifier
RES Reserved for future use
NLA ID Next-Level Aggregation Identifier
SLA ID Site-Level Aggregation Identifier
INTERFACE ID Interface Identifier
IPV6 TESTING ADDRESS ALLOCATION
Authors:
Hinden, Fink, Postel
Date: November 1998
Available at: ftp://ftp.isi.edu/in-notes/rfc2471.txt
This
document describes an allocation plan for IPv6 addresses to be
used in testing
IPv6 prototype software. These addresses are temporary
and will be reclaimed
in the future. Any IPv6 system using these
addresses will have to renumber
at some time in the future. These
addresses will not to be routable in the Internet
other than for IPv6
testing.
The Aggregatable Global Unicast Address Allocation
format defined in
[AGGR] is as follows:
| 3 | 13 |
32 | 16 |
64 bits |
+---+-----+-----------+--------+--------------------------------+
|FP | TLA | NLA ID | SLA ID | Interface
ID |
| | ID |
| |
|
+---+-----+-----------+--------+--------------------------------+
FP
= 001 and TLA = 0x1FFE. The NLA is assigned by the 6bone
administrator and
the SLA is defined by the individual organization.
The document is RFC 2471 and
is on the IETF Standards Track.
IPV6 MULTICAST ADDRESS ASSIGNMENTS
Authors:
Hinden, Deering
Date: July 1998
Available at: ftp://ftp.isi.edu/in-notes/rfc2375.txt
This
document defines the initial assignment of IPv6 multicast
addresses. It
adapts the existing IPv4 multicast address space to IPv6
and supports node-local,
site-local and link-local scope addresses.
Note that RFC 2373, IP Version 6 Addressing
Architecture, is the
document that defines rules for new IPv6 multicast addresses.
This
document is an informational RFC: RFC 2375.
RESERVED IPV6 SUBNET ANYCAST
ADDRESSES
Authors: Johnson, Deering
Date: March 1999
Available at: ftp://ftp.isi.edu/in-notes/rfc2526.txt
The
IP Version 6 addressing architecture defines an "anycast" address
as an IPv6 address
that is assigned to one or more network interfaces
(typically belonging to different
nodes), with the property that a
packet sent to an anycast address is routed to
the "nearest" interface
having that address, according to the routing protocols'
measure of
distance. This document defines a set of reserved anycast addresses
within
each subnet prefix, and lists the initial allocation of these
reserved subnet
anycast addresses.
Specifically, for IPv6 address types required to have to have
64-bit
interface identifiers in EUI-64 format, these reserved subnet anycast
addresses
are constructed as follows:
| 64
bits | 57 bits
| 7 bits |
+---------------------------------+------------------+------------+
|
subnet prefix
| 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
For
other IPv6 address types (that is, with format prefixes other than
those listed
above), the interface identifier is not in EUI-64 format
and may be other than
64 bits in length; these reserved subnet anycast
addresses for such address types
are constructed as follows:
|
n bits | 121-n bits
| 7 bits |
+---------------------------------+------------------+------------+
|
subnet prefix
| 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
The
document is RFC 2526 and is in the IETF's Standards Track.
PROPOSED TLA AND NLA
ASSIGNMENT RULES
Author: Hinden
Date: December 1998
Available at:
ftp://ftp.isi.edu/in-notes/rfc2450.txt
This document proposes rules for Top-Level
Aggregation Identifiers (TLA
ID) and Next-Level Aggregation Identifiers (NLA ID)
as defined in
[AGGR]. These proposed rules apply to registries allocating
TLA ID's
and to organizations receiving TLA ID's. TLA ID's were to be assigned
to
organizations providing transit topology. The first stage of
allocation
was proposed to allocate a Sub-TLA ID. When the recipient
had demonstrated
that they have assigned more than 90% of the NLA ID
for their Sub-TLA ID, they
will be allocated a TLA ID.
This proposal is intended as input from the IPng working
group to the
IANA and Registries. The document was superceded by a different
proposal
from the Regional Internet Registries. This document is and
informational
RFC: RFC 2450.
----------------------------------------------------------------------
Section
2: Impacts on Addressing of New Technologies
----------------------------------------------------------------------
IP
MOBILITY ARCHITECTURE FRAMEWORK
Authors: Becker, Patil, Qaddoura
Date: September
1999
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipm-arch-00.txt
This
document identifies several drivers that provide input for an IP
Mobility based
network and also describes a high level IP Mobility
architecture that extends
the current third generation IMT2000 wireless
architecture and builds on Mobile
IP concepts. The document discusses
the evolution of today's access strategyes
-- including TDMA, CDMA and
GSM -- and suggests that, as heterogeneous networks
evolve, the
mobility management provided by those netowrks must also evolve to
ensure
seamless roaming between the networks. Since the networks of
the futre will
be build on top of packet switched technology, the
document also discusses the
role of addressing and address mapping in
those new networks. The document
is currently an Internet Draft and is
a work in progress.
3G WIRELESS DATA PROVIDER
ARCHITECTURE USING MOBILE IP AND AAA
Author: (editied by) Hiller
Date: March
1999
Available at:
http://www.ietf.org/internet-drafts/draft-hiller-3gwireless-00.txt
This
draft specifies a third generation wireless architecture that is
consistent with
the requirements set by the International
Telecommunications Union (ITU) for International
Mobile
Telecommunications 2000 (IMT-2000)systems. IMT-2000 systems will
provide
wireless voice, high speed data, and multimedia services. This
draft has
been developed by the Telecommunications Industry Association
(TIA) Standards
Subcommittee TR45.6. As a guiding principle this draft
has leveraged the
use of RFCs and Internet drafts wherever possible,
including Mobile IP and AAA.
A network reference model is provided,
along with a set of more detailed requirements.
The document suggests
that Mobile IP services will support both statically and
dynamically
assigned home addresses. A mobile may indicate a request for a dynamic
home
address assignment in the Mobile IP RRQ, or a mobile may indicate
a
static
address. Home addresses may be public or private. The document
is currently
an Internet Draft and is a work in progress.
PRIVATE ADDRESSES IN MOBILE IP
Authors:
Perkins, Montenegro, Calhoun
Date: June 1999
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-privaddr-00.txt
The
document discusses the use of possibly non-unique private addresses
(i.e., addresses
that are not globally routable in the internet) for
mobile nodes, foreign agents,
or home agents is not handled by RFC
2002. Full-scale deployment of
Mobile IP would benefit from an
ability to provide mobility across differing address
spaces, sometimes
called "realms", especially because corporate networks often
use
private address spaces. It also specifies changes to enable Mobile IP
to
handle such addresses. The document is currently an Internet Draft
and is
a work in progress.
NAI RESOLUTION FOR WIRELESS NETWORKS
Authors: Aravamudhan,
O'Brien, Patil
Date: October 1999
Available at:
http://www.ietf.org/internet-drafts/draft-aravamudhan-mobileip-nai-
wn-00.txt
RFC
2486 defines the need of a standardized format for identifying ISP
subscribers
for dial-up roaming operations. It introduced the Network
Access Identifier (NAI)
to fulfill this need. The NAI is provided by
the mobile node to the dialed ISP
during PPP authentication. The
ability to resolve an NAI for second and
third generation cellular
mobile nodes allow traditional cellular service providers
to evolve
their home cellular networks to provide cellular services, IP packet
data
services and so on with a single subscription using NAIs.
Additionally, this allows
cellular provider to evolve their networks to
be IP based.
Second and third
generation cellular mobile nodes must perform a
registration and authentication
process with their wireless service
provider before the mobile node user may initiate
other operations .
These mobile nodes do not support the programming of an NAI
nor does
the cellular registration message support the transfer of an NAI to the
wireless
access network. For example, North American cellular networks
(e.g. AMPS, TDMA,
CDMA) service mobiler nodes that register with a
Mobile Identification Number
(MIN). The MIN is then associated with a
cellular subscriber. MIN is shown here
only as an example, the same
general idea is applicable to other types of identifiers
used in
different access network types. It would be convenient if an option was
available
to provide the wireless subscriber identification in the form
of an NAI during
the wireless registration and authentication process.
This document proposes a
solution to resolve NAIs from traditional
mobile node identifiers. The document
is currently an Internet Draft
and is a work in progress.
EURESCOM P909 CONTRIBUTION
TO PINT AND SPIRITS INTERACTION BETWEEN
INTERNET AND PSTN TO REQUEST SERVICES
FROM ONE DOMAIN TO THE OTHER
Authors: Blavette, Canal, Herzog, Licciardi, Tuffin
Date:
February 2000
This document is intended to provide input to the IETF
SPIRITS
Working Group (SPIRITS WG) and to the IETF PINT Working Group (PINT WG)
from
the viewpoint of European network operators that are involved
in
EURESCOM P909 Project "Enabling Technologies for IN Evolution and
IN-Internet
Integration". The input is based on current results that
were achieved in the
project. As the project title says P909 project
deals with IN-Internet integration
issues. The project has defined an
architecture for IN-Internet inte gration
and it has selected and
described some IN-Internet services which can be
interesting from the
business perspective and challenging from the technical perspective.
Some
of these services are "officially" chartered in IETF: ICW in
SPIRITS,
Click-to-Dial (Request to Call) as well as proposed
Conference Service in PINT.
However, there are additional IN-Internet
convergence services that P909
studies and that are included in this
document only as examples. Selected
services can help in defining
requirements both in the context of
how services supported by IP
network entities can be started from IN (Intelligent
Network) requests
and how Internet applications can request and enrich PSTN
(Public
Switched Telephone Network) telephony services. Section 2 and 3
of the
document provides some general information on the EURESCOM and P909
project.
The document is currently an Internet Draft and is a work in
progress.
TELECOMMUNICATIONS
AND INTERNET PROTOCOL HARMONIZATION OVER NETWORKS:
NUMBERING
Author: ETSI
Date:
November 1999
Available as: c9c010cr.PDF at http://www.etsi.org
This document
discusses numbering and addressing schemes -- along with
required functionality
-- for TIPHON compliant networks. Four options
are discussed: calls from
IP-based terminals to terminasl in a switched
network; from terminals in a switched
network to IP-based terminals;
from terminals in switched networks through IP-based
networks; and
finally from terminals in IP-based networks through the switched
networks.
The document describes the naming and numbering schemes
needed within the network
to identify users and terminals in either IP-
based networks or switched networks.
TECHNICAL
SPECIFICATION GROUP SERVICES AND SYSTEM ASPECTS: ADVANCED
ADDRESSING
Author:
3rd Generation Partnership Project
Date: October 1999
Available as: 3G TR 22.975
(Technical Report) at http://www.3gpp.org
This document identifies the kep features
of UTMS' advanced addressing
scheme and requirements for numbering and addressing
in UTMS. The
document describes examples of directory, application and translations
mechanisms
that would be built on the addressing strategy. A key
requirement is the
need for UMTS users to be able to internetwork with
users in legacy environments.
This requirements document is being used
to develop a proposal for advanced addressing
and numbering systems for
UTMS. The document also discusses the need for
address translation
capabilities across transport gateways.
GLOBAL CIRCULATION
OF IMT-2000 TERMINALS
Author: European Radiocommunications Committee
Date:
October 1999
Available at: http://www.utms-forum.org/
This report considers
the need for global circulation of IMT-2000
terminal equipment and how support
for administrative, addressing and
policy issues would be managed in such an environment.
In addition to
discussing the physical layer for transport, the paper discusses
administrative
mechanisms for supporting global roaming of IMT-2000
terminals. Global roaming
requires terminal identification and the
ability to pass identity and addressing
information from one provider
to another. This report considers mechanisms
for supporting a variety
of terminal types in heterogeneous networks.
THE FUTURE
MOBILE MARKET
Author: UMTS Forum
Date: March 1999
Available at: http://www.utms-forum.org/
This
report assesses the anticipated future market for mobile
multimedia services as
well as mobile voice and data services. The
report has been updated since
an original study in 1997 that includes
projected growth in mobile users and satellite
traffic. In particular
it suggests that there will be 426 million users
of terrestrial mobile
services by the end of this year, 940 million by 2005 and
more than 1.7
billion by 2010. It is also projected that there will be 190
million
physical mobile users in North America by 2005, rising to 220 million
by
2010. The report predicts that there will be 400 million physical
mobile
users in the Asia Pacific region by 2005. The Western European
marketplace
will see total traffic levels of 63 Terrabytes/month.
A PROPOSAL FOR THE PROVISIONING
OF PSTN INITIATED SERVICES RUNNING ON
THE INTERNET
Author: Buller
Date:
September 1999
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-pint-saint-00.txt
This
Internet Draft has arisen out of work concentrating on the
interconnection of
IP and the Public Switched Telephone Network
(PSTN) undertaken within the PINT
working group. Efforts within this
group have, to date, concentrated on the initiation
of PSTN services
from the Internet. This Internet Draft aims to describe
a possible
architecture for th implementation of services initiated from the PSTN
such
as, but no limited to, Internet Call Waiting (ICW). It also
identifies th possibility
of using this class of service, in
conjunction with the PINT work already undertaken,
in order to provide
a third flavour of service. The proposal suggests that
the schemes for
translating Calling Line Identity into actual locations (through
translations
of addresses or other schemes) is a protocol or profile
that would arise out of
future work. The document is currently an
Internet Draft and is a work in
progress.
Two documents from a recent ITU-T SG11 meeting in Geneva, March 1-19,
1999
also address the interconnection of IP and the Public Switched
Telephone Network:
INIP_arch.doc (MS-Word)
http://www.bell-labs.com/mailing-lists/pint/INIP_arch.doc
describes the
IN functional architecture in support of PINT and IP telephony
services;
INIP-flows.doc (MS-Word) available at:
http://www.bell-labs.com/mailing-lists/pint/INIP_flows.doc
describes
the message flows for click-to-dial, click-to-fax, and Internet call
waiting
services.
ENUM REQUIREMENTS
Author: Brown
Date: November 1999
Available
at:
http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-00.txt
This paper
defines the requirements for a DNS-based architecture and
protocols for mapping
a telephone number to a set of attributes (e.g.,
URLs) which can be used to contact
a resource associated with that
number. There are many possible protocols that
can be considered for a
telephone number mapping service. The purpose of
this document is to
focus discussion on a DNS-based rather than an address-to-address
sytle
solution. The document is currently an Internet Draft and is a work
in
progress.
URLS FOR TELEPHONE CALLS
Author: Vaha-Sipila
Date: December
1999
Available at:
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-12.txt
This
document specifies URL (Uniform Resource Locator) schemes ''tel'',
''fax'' and
''modem'' for specifying the location of a terminal in the
phone network and the
connection types (modes of operation) that can be
used to connect to that entity.
This specification is intended to cover
voice calls (normal phone calls, answering
machines and voice messaging
systems), facsimile (telefax) calls and data calls,
both for POTS and
digital/mobile subscribers. The proposal is currently
an Internet
Draft and is a work in progress.
E.164 RESOLUTION
Author: Brown
Date:
October 1999
Available at:
http://www.ietf.org/internet-drafts/draft-brown-e164-01.txt
This
paper addresses global access to address information and
additional subscriber
and equipment information, given a telephone
number as input. The
proposal uses a directory structure to provide
clients with the ability to access
directory information, given only a
telephone number. The directory is structured
according to the E.164
numbering plan, with each node in the tree representing
a single digit
of an E.164 telephone number. Given a telephone number, an LDAP
or DNS
query can pinpoint an entry in the global tree. This structure allows
Information
Consumers to retrieve information without having to perform
a global search for
a telephone number and without having to understand
different numbering plan structures.
The proposal is currently an
Internet Draft and is a work in progress.
----------------------------------------------------------------------
Section
3: General and Tutorial documents
----------------------------------------------------------------------
UNDERSTANDING
IP ADDRESSING: EVERYTHING YOU EVER WANTED TO KNOW
Author: Chuck Semeria
Date:
Unknown
Available at: http://www.3com.com/nsc/501302.html
This paper is a tutorial
on IP Addressing in the public Internet. In
discusses Internet scaling
problems, the difrference between
historical, classful addressing and CIDR, subnetting,
routing and route
aggregation,
control of the growth of routing tables, how
routing works in a
classless environment, and strategies for address conservation
that
appeared in the late 1990's. The document is intended primarily as
a
tutorial.
GENERAL PACKET RADIO SERVICE
Author: Peter Ryavvy
Date: September
1998
Available at: http://www.gsmforum.org/
This report is a description
of packet based mobile transports that
support IP. GPRS will operate at
higher speeds than current mobile
networks provide and, as a result, is an important
development for
mobile data networks. GPRS supports direct IP access where
a customer
makes a circuit-switched call but rather than switching the cal into
the
public switched fabric, the carrier that terminates it at a router
that is connected
to the public Internet. The potential requirements
for addressing in the
GPRS environment are discussed as well as a
timeline for deployment of the technology.
----------------------------------------------------------------------
DOCUMENT
VERSION
This is version one of this bibliography, February 2000.
CONTACT
INFORMATION
This document was compiled by Mark McFadden, Commercial Internet
eXchange,
Herndon, Virginia. Any errors or ommissions are my
responsibility and corrections,
suggestions, and proposals for further
contributions are welcomed by the editor:
Mark
McFadden
mcfadden@cix.org
PO Box 7102
Madison, Wisconsin 53707-5707
US